[Wayland-bugs] [Bug 770333] New: GdkSelection does not support arbitrary named clipboards/selections on wayland

[gtk+ (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=770333

            Bug ID: 770333
           Summary: GdkSelection does not support arbitrary named
                    clipboards/selections on wayland
    Classification: Platform
           Product: gtk+
           Version: 3.21.x
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: Backend: Wayland
          Assignee: gtk-bugs at gtk.org
          Reporter: thomas at tommie-lie.de
        QA Contact: gtk-bugs at gtk.org
                CC: rob at robster.org.uk, wayland-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 334080
  --> https://bugzilla.gnome.org/attachment.cgi?id=334080&action=edit
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-bugs/attachments/20160824/703b278b/attachment.html>