GNOME Bugzilla – Bug 694217
drag&drop half-broken – items get stuck while dragging
Last modified: 2018-04-15 00:05:00 UTC
When I drag some specific things, like files in Nautilus, or text selections in Gedit, I can't drag the object more than approx. 10-30 px – then it just gets stuck and cannot be dragged further or dropped anywhere (the mouse pointer still moves, the object does not). I'm not sure how to clearly describe it, but this seems to only happen when the program displays a custom icon when dragging (for example, when dragging a file in Nautilus) – and does not happen when the generic "page" icon is shown (e.g. when dragging a pathbar item in Nautilus).
forgot to include gtk version is 3.7.10-45-g3c690c5, but this seems to have broken somewhere between 69f4574 (good) and 15ee04c (bad)
*** Bug 694557 has been marked as a duplicate of this bug. ***
*** Bug 694707 has been marked as a duplicate of this bug. ***
Have this tracked down - the following patch "fixes" it: diff --git a/gtk/gtkdnd.c b/gtk/gtkdnd.c index 42f7221..4b974a5 100644 --- a/gtk/gtkdnd.c +++ b/gtk/gtkdnd.c @@ -360,7 +360,7 @@ gtk_drag_get_ipc_widget_for_screen (GdkScreen *screen) result = gtk_window_new (GTK_WINDOW_POPUP); gtk_window_set_screen (GTK_WINDOW (result), screen); gtk_window_resize (GTK_WINDOW (result), 1, 1); - gtk_window_move (GTK_WINDOW (result), -100, -100); + gtk_window_move (GTK_WINDOW (result), -99, -99); gtk_widget_show (result); } The explanation here is that override-redirect windows that are -100-100+1+1 when created are magically ignored by Mutter, even if they are InputOutput. This causes: A) GTK+ thinks it will get _NET_WM_FRAME_DRAWN on the window after it is initialy mapped B) Mutter doesn't send it So the IPC window gets in a stuck state and no events are delivered to it. I think that the Mutter code just needs to be removed - it would be perfectly valid to create such a window then move it onscreen, and the cost of one more TFP and actor isn't very big. Possibly also we should try to make this window InputOnly again so mutter can legitimately ignore it, and the GDK code will know not to expect _NET_WM_FRAME_DRAWN. See bug 347277 for the history - this window used to be a GtkInvisible, but then to set the window group it was switched to a GtkWindow.
I suppose mutter has a fix for it and this is for backwards compatibility. So feel free to push it.
Pushed this for now
That wasn't meant to be a real patch! Was not suggesting it for GTK+ at all, just describing the problem.
reopening this bug to wait for a better fix
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new