After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 766442 - Broken drag & drop between windows
Broken drag & drop between windows
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: GtkNotebook
3.20.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
: 766656 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2016-05-14 14:49 UTC by Cédric Bellegarde
Modified: 2016-06-15 09:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
x11/dnd: Ignore grab broken events from other devices than our DnD device. (1.19 KB, patch)
2016-05-17 18:03 UTC, Carlos Garnacho
committed Details | Review

Description Cédric Bellegarde 2016-05-14 14:49:56 UTC
Since GTK 3.20-4, drag & drop is broken between different windows.

Happen in Gnome Terminal while draging tabs...

More informations here:
https://github.com/FreeRDP/Remmina/issues/861#issuecomment-219211236
Comment 1 Frederic Peters 2016-05-17 05:48:17 UTC
I observe a similar issue with GTK+ master (cd305c1), even worse it's also broken when dragging in the same window. (tested with tests/testnotebookdnd).

Actually I can drag tabs if the mouse stay over the notebook tabs but when moving too far away (like ~20pixels) the dragged tab is moved back to the notebook (from the position it had or strangely the top left of the screen).
Comment 2 Cédric Bellegarde 2016-05-17 13:21:37 UTC
Broken in same window with GTK 3.20.4 too
Comment 3 Carlos Garnacho 2016-05-17 18:02:42 UTC
This was a funky one. It's apparently introduced by commit c14572fdae9bf6d34cd6af35dc572c509f1ae144 , now that we set up passive grabs for DnD, what happens is that:

1) gtk_notebook_drag_begin() tries to set the tab widget as the DnD widget, so it hides it first in order to reparent
2) To gdk, the tab window still has the keyboard focus, thus hiding the window triggers grab broken events for the keyboard
3) gdkdnd-x11.c doesn't perform device checks on grab broken events, so ends up cancelling dnd.

I'm not sure if we can do much about the implicit keyboard grab broken, it's probably a good idea to listen to grab broken events from the pointer though, I'm attaching a patch doing that.
Comment 4 Carlos Garnacho 2016-05-17 18:03:47 UTC
Created attachment 328095 [details] [review]
x11/dnd: Ignore grab broken events from other devices than our DnD device.

The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.
Comment 5 Matthias Clasen 2016-05-18 02:41:25 UTC
Review of attachment 328095 [details] [review]:

Makes sense
Comment 6 Carlos Garnacho 2016-05-18 10:57:08 UTC
Pushed with a small touchup (don't consume grab broken events not meant to us)

Attachment 328095 [details] pushed as 1d04bdf - x11/dnd: Ignore grab broken events from other devices than our DnD device.
Comment 7 Matthias Clasen 2016-05-19 11:57:36 UTC
*** Bug 766656 has been marked as a duplicate of this bug. ***
Comment 8 Emmanuele Bassi (:ebassi) 2016-06-15 09:40:39 UTC
*** Bug 767588 has been marked as a duplicate of this bug. ***