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,
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
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).
@@ +99,3 @@
/* Destination-side data */
+ SelectionData selections;
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