In gtk applications, one can use the clipboard in different ways: either just using the two convenience functions (if you will) gtk_clipboard_set_text() and gtk_clipboard_set_image(). When using these, clipboard data persists when one exits a program( this is due to gtk automatically calling gtk_clipboard_set_can_store() when one is calling these. If gtk_clipboard_set_can_store() is set properly, clipboard data can be stored to the freedesktop clipboard manager (http://www.freedesktop.org/wiki/Specifications/clipboard-manager-spec) which gnome implements. The transfer to the clipboard will happen once gtk_clipboard_store() is called, or when the application main loop exits. Steps to reproduce: 1. open a webkit-gtk browser( I used epiphany) 2. copy some text to the clipboard (not selection clipboard) 3. open gedit, paste it there (this should work) 4. quit epiphany, try to paste again (this does not work) This bug affects a couple of programs in the linux desktop (for instance firefox), so to see the clipboard manager working as intended try to use for instance gedit in a gnome environment (if you quit gedit, its clipboard data should persist).
as i know, its a longstanding GTK bug in general. not a webkit
(In reply to comment #1) > as i know, its a longstanding GTK bug in general. not a webkit No it's not really a gtk bug, there are properly working gtk apps (such as gedit)
This works with Clipman in XFCE 4.6. So is this really a problem with WebKitGTK+? From a look at GTK+ sources the default clipboard is stored automatically. And surely GTK+ doesn't expect all existing applications to handle this manually. I might be wrong.
I can confirm this bug in Epiphany and Empathy using Webkit-1.3.2 in Ubuntu 10.04. Clipboard managers such as Klipper (a part of KDE), Glipper, Parcellite and Clipman work around this problem so it's expected that you wouldn't be able to reproduce it if you're running one of those. It's not a GTK+ bug; that is to say, gtk provides the functions ickard mentioned so that applications can save their data before they exit. It would be nice if existing applications didn't have to handle it manually, but right now gtk_clipboard_set_can_store()/gtk_clipboard_store() are the right way of fixing it.
Created attachment 61225 [details] Sets gtk_clipboard_set_can_store when clipboard is acquired to fix bug #27411: clipboard lost on exit.
Comment on attachment 61225 [details] Sets gtk_clipboard_set_can_store when clipboard is acquired to fix bug #27411: clipboard lost on exit. WebKit/gtk/webkit/webkitwebview.cpp:3565 + NULL, 0); Two things: no need to break the line here, in WebKit code we're used to longer lines, and this makes a bit more readable. Also, the style guidelines say we should use 0 instead of NULL (though we do use NULL in a few cases we get warnings otherwise). As for the content, it looks sane to me, but I'd like to hear mrobinson's opinion as well, since he's the one who's been working on clipboard/dragndrop the most recently (I'll poke him). Also, we might also want to save the PRIMARY clipboard, right? I'll say r- for now, because we need a ChangeLog entry. I assume you are not a committer, so you may want to set commit-queue to ? as well, so that the person who reviews your patch can make the patch be automatic committed for you =).
Created attachment 61234 [details] Sets gtk_clipboard_set_can_store when clipboard is acquired. With changes suggested by kov: https://bugs.webkit.org/show_bug.cgi?id=27411#c6
I didn't add a primary buffer save because there's some disagreement on whether it makes sense conceptually. I think the argument against it is that primary selection isn't meant for workflow where you'd need clipboard persistence. The argument for it is of course preserving more information the user might want. It should be straightforward to add primary save support. I'll up a new patch once I've tested that.
Patch looks good, but this may not be the correct place to call these functions. Having the change here means that not all code paths which set the clipboard will get this fix. Perhaps it would make more sense to do it here: http://trac.webkit.org/browser/trunk/WebCore/platform/gtk/PasteboardHelper.cpp#L286 in writeClipboardContents. Please consider this change. Thanks!
Created attachment 61256 [details] Sets gtk_clipboard_set_can_store in WebCore. With changes suggested by mrobinson: https://bugs.webkit.org/show_bug.cgi?id=27411#c9
This looks good to me! A reviewer will have to do the r+.
Created attachment 61822 [details] Sets gtk_clipboard_set_can_store in WebCore. With updated information about testing the behaviour.
Comment on attachment 61822 [details] Sets gtk_clipboard_set_can_store in WebCore. With updated information about testing the behaviour. Very good, thanks!
Comment on attachment 61822 [details] Sets gtk_clipboard_set_can_store in WebCore. With updated information about testing the behaviour. Rejecting patch 61822 from commit-queue. Failed to run "[u'/Users/eseidel/Projects/CommitQueue/WebKitTools/Scripts/svn-apply', u'--reviewer', u'Gustavo Noronha Silva', u'--force']" exit_code: 2 Parsed 2 diffs from patch file(s). patching file WebCore/ChangeLog patch: **** malformed patch at line 21: + I haven't included an automated test because of the difficulty of testing behaviour after application exit. patching file WebCore/platform/gtk/PasteboardHelper.cpp Full output: http://webkit-commit-queue.appspot.com/results/3562073
Created attachment 61827 [details] Sets gtk_clipboard_set_can_store in WebCore. With malformed patch fix
Comment on attachment 61827 [details] Sets gtk_clipboard_set_can_store in WebCore. With malformed patch fix let's try again
Comment on attachment 61827 [details] Sets gtk_clipboard_set_can_store in WebCore. With malformed patch fix Clearing flags on attachment: 61827 Committed r63587: <http://trac.webkit.org/changeset/63587>