brl/mutter
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

xwayland: Ignore selection request not meant to our internal window

Browse Source 
There may be other windows managing selection whose events are seen in
our GDK event filter, like st-clipboard in gnome-shell, we should in
that case not interfere on Selection/SelectionRequest events that are
not meant for us.

This fixes an odd feedback loop where requesting clipboard contents from
wayland results in a XConvertRequest call and a SelectionRequest event
that is interpreted by mutter as a request from another X11 client, so
the current data source is poked for content, which happens to be the
X11 bridge, which does a XConvertRequest to get contents... This is only
broken after the many nested async operations create enough pipes and
cancellables to run out of fds.

Adding checks to ensure only events meant to our "selection owner"
window are managed prevent this unintended loop to happen in the first
place.

https://bugzilla.gnome.org/show_bug.cgi?id=760745
This commit is contained in:
Carlos Garnacho 2016-10-07 13:58:35 +02:00
parent a9e386e1af
commit b3eac93c4c
1 changed files with 6 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
src/wayland/meta-xwayland-selection.c
View File

@ -1129,6 +1129,9 @@ meta_xwayland_selection_handle_selection_notify (MetaWaylandCompositor *composit
if (!selection)
return FALSE;
if (selection->window != event->requestor)
return FALSE;
/* convert selection failed */
if (event->property == None)
{
@ -1261,6 +1264,9 @@ meta_xwayland_selection_handle_selection_request (MetaWaylandCompositor *composi
if (!selection)
return FALSE;
if (selection->window != event->owner)
return FALSE;
/* We must fetch from the currently active source, not the Xwayland one */
data_source = data_device_get_active_source_for_atom (&compositor->seat->data_device,
selection->selection_atom);