GNOME Bugzilla – Bug 770940
wayland/xwayland: Gracefully handle Xdnd start drag focus race
Last modified: 2016-09-15 02:34:58 UTC
This probably fixes https://bugzilla.redhat.com/show_bug.cgi?id=1288875 . The way I reproduced this was applying the following patch to gtk+: diff --git a/gtk/gtkdnd.c b/gtk/gtkdnd.c index c9f34e2..e0b5e61 100644 --- a/gtk/gtkdnd.c +++ b/gtk/gtkdnd.c @@ -2507,6 +2507,7 @@ gtk_drag_source_check_selection (GtkDragSourceInfo *info, { GList *tmp_list; + usleep(1000000); tmp_list = info->selections; while (tmp_list) { and then, by using GDK_BACKEND=x11 ./testdnd in gtk+/tests/ start the drag, and quickly release outside of the window, before the above sleep had completed. Without the attached patch this would crash mutter. The focus surface is used as a "drag origin" in the DND feedback actor. Not sure what exactly it's fore (Carlos?), but I found no way to get the correct drag origin for Xdnd by just looking at the received event. Maybe there is a better way than just lookig at what happens to be focused. After this patch, the Xwayland dnd integration accepts any arbitrary Xwayland surface to be focused for using as a drag origin.
Created attachment 334892 [details] [review] wayland/xwayland: Gracefully handle Xdnd start drag focus race If a X11 client would initiate a Xdnd session after it had lost pointer focus (for example when the Xdnd event starting the drag happens after the implicit pointer grab is already broken due to the button being released), just end the drag operation instead of dereferencing the non-existing focus surface. Also avoid using a native Wayland surface as a drag origin, as that can never happen, but allow any arbitrary Xwayland client, since there is no way to find out the actual drag origin.
Comment on attachment 334892 [details] [review] wayland/xwayland: Gracefully handle Xdnd start drag focus race Indeed, it makes sense to double check things here.
Attachment 334892 [details] pushed as b1d9543 - wayland/xwayland: Gracefully handle Xdnd start drag focus race