GNOME Bugzilla – Bug 770333
GdkSelection does not support arbitrary named clipboards/selections on wayland
Last modified: 2017-05-01 18:33:03 UTC
Created attachment 334080 [details] Sample program that reproduces the bug. GtkClipboard allows "arbitrary named clipboards" (besides "PRIMARY" and "CLIPBOARD") and makes use of of the GdkSelection functions to access them. Using this feature makes e.g. gtk_clipboard_wait_for_targets() wait forever because the gdk_selection_* functions will never return the correct selection data. backstory: file-roller uses its own clipboard name ("_FR_SPECIAL_CLIPBOARD"). With the recent update from my distribution to Gtk+ 3.20.9, my file-roller was unable to extract from or navigate within an archive in Wayland. The X11 backend worked fine. A simple test is to use the latest Gtk+ and file-roller in a Wayland session and open an archive. All the context menu items in file-roller are greyed out as is the "Extract" button in the top left corner. cause(-ish): The misbehaviour was introduced in https://git.gnome.org/browse/gtk%2B/commit/?id=0d30ad2 (before this, file-roller worked fine) but I think it might just be that it made the error more obvious. The problem with the commit is that _gdk_wayland_display_convert_selection() now immediately returns if the selection with the given atom cannot be found. As it can never find file-roller's custom-named selection, it always returns early without doing anything useful. I'm not sure whether the behaviour before the commit was a 100% correct, either, because there actually is no selection with the given atom on wayland and it can never be created. It might be that some features of file-roller were not working correctly even before. Right now, file-roller has just become unusable because it breaks sooner. reproduce: See the attached sample program which basically mimics what file-roller does. Observe that with latest Gtk+ (with 0d30ad2 applied), the program will never terminate in a wayland session (the effect in file-roller is that the UI is unusable). Using GDK_BACKEND=x11 works, the program returns as expected. Using any version before said commit also works.
Downstream bug: https://bugzilla.redhat.com/show_bug.cgi?id=1374321
Created attachment 335541 [details] [review] Use the X11 backend instead of Wayland Force file-roller to use the gtk+ X11 backend even when running under a Wayland session. This is currently needed to work around missing support for arbitrarily named clipboards.
for file-roller, I guess we can easily workaround the issue in the code though, by not using its own clipboard - I guess users can live without that feature.
So, funny story: File Roller uses GtkApplication without G_APPLICATION_FLAGS_NON_UNIQUE, which means it's a single-instance application. This means that this whole IPC weirdness to handle drag and drop of files can just be replaced by storing data on the application singleton, since all windows come from the same process.
When I analyzed file-roller for the bug, I did not really understand why it has its own clipboard. I thought it was for drag-and-drop to/from other file-roller instances, but that works fine even on Wayland with the older version of Gtk+. I did not really focus on finding out *why* file-roller uses the clipboard, though. Eliminating dead code in file-roller (if it really is not necessary) is definitely a good idea. But this is still a bug either in Gtk+'s API documentation (which explicitly states that custom clipboards can be created this way) or the Wayland backend implementation (if Gtk+ developers think that custom clipboards are a feature worthwhile having).
We cannot change gtk_widget_get_clipboard() because the documentation says it returns a GtkClipboard object — but what we *can* do is return a dummy, inert GtkClipboard object depending on platform-specific conditions, one of which would be that on Wayland there are no named clipboards outside of the clipboard and primary ones.
doing so should probably be preceded by moving most of the clipboard implementation into the backends.
Wouldn't it be better to turn atoms and _GdkWaylandSelection.selections in gdkselection-wayland.c into a GArray, GList or maybe even a GHashTable and make the GdkWaylandSelection backend aware of custom clipboards? I don't know too much about this but mimicking X11's behaviour should already be possible in the Wayland backend. Is this something worth working on right now or would this be wasted time?
In theory we don't need that much, GtkSelection/GtkClipboard already have code to bypass windowing if the selection owner is local, we probably could do with just faking enough of a successful selection ownership change to trigger it. But this is all about making it work locally to the process. We can't export arbitrary selections to other clients.
Just to let you know, I've now removed the custom clipboard from file-roller (commit 26765b8), this change will be available from version 3.22.1.
I had to revert the change because I found out a use case where a different clipboard is useful, a detailed description is in the commit df19186483a5e3edf2ff89cfd92c30bf85b9420f
(In reply to Paolo Bacchilega from comment #11) > I had to revert the change because I found out a use case where a different > clipboard is useful, a detailed description is in the commit > df19186483a5e3edf2ff89cfd92c30bf85b9420f That particular use case is supported by not using a GdkSelection to store the list of selected files in the first place. The only reason why you would use a GdkSelection is, on X11, to use the X protocol as a form of IPC between two separate instances of file-roller; since file-roller is a single-instance application, there's no reason to use a GdkSelection to hold some URIs, since there's no IPC taking place. 'Cut'/'Copy'/'Paste' operations should be implemented inside the file-roller application singleton, by storing row references to the GtkTreeView, or by storing a list of URIs. Even if file-roller were to support multiple instances of the application, you should use a better IPC mechanism, like DBus, instead of the X protocol, as it has unknown latencies (which depend on things like your GPU stalling the event queue) and a woefully inadequate type system.
I think this bug is more or less fixed in 3.24.1 with https://git.gnome.org/browse/file-roller/commit/?id=e071c0fad Here's a few things that still don't work in GNOME on Wayland but work with GNOME on X: 1. Drag and drop a file from an archive in File Roller to Nautilus (although the reverse works and Extract on an individual file works) 2. External copy-and-paste from an archive in File Roller to Nautilus or from Nautilus to the archive in File Roller. Let me know if you would rather I file a different bug report for these issues.
Separate bug, please.
Is there a rationale for the WONTFIX? This bug is about GdkSelection behaving differently in Wayland and X11 and different from what it says in the documentation. While there may be workarounds for file-roller, shouldn't we at least change the documentation?
The bug is fuzzy about its intent; it should probably be clarified — or a new bug about the documentation ought to be opened. No backend outside of the X11 one already supports named selections outside of CLIPBOARD and PRIMARY, so the documentation should say that only those two are guaranteed to exist in GDK.
> Is there a rationale for the WONTFIX? wayland doesn't support arbitrary clipboard names. and that is what this bug was asking for. And the underlying file-roller issue does not exist anymore...