From b3eac93c4cef1b3ca6748cd95544ac720ee40821 Mon Sep 17 00:00:00 2001 From: Carlos Garnacho Date: Fri, 7 Oct 2016 13:58:35 +0200 Subject: [PATCH] xwayland: Ignore selection request not meant to our internal window 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 --- src/wayland/meta-xwayland-selection.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/wayland/meta-xwayland-selection.c b/src/wayland/meta-xwayland-selection.c index 5735fe438..a8806f17e 100644 --- a/src/wayland/meta-xwayland-selection.c +++ b/src/wayland/meta-xwayland-selection.c @@ -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);