GNOME Bugzilla – Bug 768177
CLIPBOARD target request after PRIMARY request times out. GDK_SELECTION_NOTIFY has wrong selection id
Last modified: 2016-07-02 16:58:16 UTC
Created attachment 330565 [details] [review] this makes it work for me LibreOffice under wayland won't successfully paste from the CLIPBOARD after the PRIMARY selection is used to paste from another app into it. I paste from PRIMARY and then immediately request the targets of CLIPBOARD: selection_buffer_notify generates a GDK_SELECTION_NOTIFY event for this CLIPBOARD request using selection_buffer_notify but sets the selection field to PRIMARY from the passed in SelectionBuffer. So the notification dosn't match in _gtk_selection_notify at the info->selection == event->selection so the CLIPBOARD request is never satisfied and times out. The problem appears to be the cache used by _gdk_wayland_display_convert_selection of gdk/wayland/gdkselection-wayland.c where... buffer_data = g_hash_table_lookup (wayland_selection->selection_buffers, target); ... g_hash_table_insert (wayland_selection->selection_buffers, GDK_ATOM_TO_POINTER (target), buffer_data); So the buffer_data for the PRIMARY selection was cached and reused for the CLIPBOARD selection. The attached patch "for for me(tm)" by just updating the selection of the cached buffer_data to the requested selection on retrieval
Yikes, nice catch! However, I think the shared SelectionBuffer ht across all selections bring more issues than this, I think it's better to just separate buffers into the different selections. I'm attaching a patch doing so, would be great if you could try it and confirm it still fixes your issue.
Created attachment 330600 [details] [review] wayland: Separate selection buffers and other per-selection atom data This has most notably impact in selection buffers, because those were shared across all selection atoms. This turned out wrong on 2 situations: - Because the selection atom was set at SelectionBuffer creation time, the GDK_SELECTION_NOTIFY events generated will have unexpected info if the buffer is attempted to be reused for another selection. - Anytime different selections imply different stored content for the same target. This is better separated into per-selection buffers, so it's not possible to get collisions if a same target is used across different selections.
Yup, that works perfectly fine for me
Review of attachment 330600 [details] [review]: As far as I can tell, this looks correct to me (with one minor nit). ::: gdk/wayland/gdkselection-wayland.c @@ +99,3 @@ { /* Destination-side data */ + SelectionData selections[3]; nit: Could just as well now add a ATOM_LAST or N_ATOMS to the enum, and use that instead of the 3s? Makes it more obvious what is in the arrays as well.
Sure :), adding that and pushing.
Attachment 330600 [details] pushed as 0d30ad2 - wayland: Separate selection buffers and other per-selection atom data