GNOME Bugzilla – Bug 664646
dnd pointer lock when dragging tab between two gedit instances
Last modified: 2015-01-06 12:14:02 UTC
this report has been filed here: https://bugs.launchpad.net/ubuntu/+source/gedit/+bug/880962 "When I start two instances of gedit (for example manual opening and opening a file) and dragging from one tab to the other freezes the complete desktop (unity and gnome-shell). When i look at the processes i only see one gedit instance running. If i kill it the gui is free." "the mouse pointer changes to an hand when the drag start but something seems to stop the dnd on its way, the widget stays floating and stop moving and the mouse cursor stays stucked in grab state"
Is this dragging selected text from one window to the other or dragging the entire tab? Either way I cannot reproduce here... Can the problem be reproduced systematically or just some of the times?
it's happening when dragging the tab and every time but you need to run gedit twice using different ways, i.e one from a command line and one by double clicking on a txt in nautilus
I can confirm this happening on Fedora 16 with GNOME 3.2
Not reproducing it here. If I open two windows in the same process, I can drag tabs from one window to the other without lockups. If I run two separate gedit processes (using -s), dragging a tab from one and dropping it over the other opens a new window, again without lockups.
Mathias, indeed, if you do as you say, I can't reproduce either, but if I do as Sebastien said (by clicking on nautilus in one txt file and running gedit from the terminal) I get the lockup.
Here's how it happens to me: 1. Start gedit from a Unity launcher. 2. Open a file in gedit from the right-click menu on its Nautilus icon. 3. Drag a tab from either window to the other. 4. When the pointer enters the second window, it hangs. You can't reverse 1 and 2 because the launcher will focus the open window instead opening a new one. There is only one gedit process. Since the hang occurs when the pointer enters the other gedit window, I'm guessing the bug is due to a failure to switch back to the xdnd mode for within-app dnd. Maybe the switch is the problem. Maybe not switching is it; I can imagine the stack gets ugly when an app is both sender and receiver. Running xprop on both windows yields differences in the following properties: 1. WM_WINDOW_ROLE 2. WM_CLIENT_LEADER 3. window id # of group leader There are other differences, but I remember enough to be sure they're not relevant. (Which is not to say those 3 are; I just can't rule them out.)
*** Bug 670428 has been marked as a duplicate of this bug. ***
When launched from nautilus, $DISPLAY=:0.0 Elsewhere, $DISPLAY=:0 If you do export $DISPLAY=:0.0 in a terminal, then gedit launched from nautilus and gedit launched from the terminal interact properly.
Created attachment 213889 [details] [review] avoid an infinite loop This patch deals with the hang but doesn't fix the whole problem with mismatched $DISPLAY values.
Created attachment 213995 [details] [review] GDK X11 DND: Fix infinite loop Same patch but nicely git formatted.
Review of attachment 213995 [details] [review]: thanks
*** Bug 654952 has been marked as a duplicate of this bug. ***
*** Bug 676617 has been marked as a duplicate of this bug. ***
as per launchpad link this this issue is fixed, any can confirm this?, can we close this report?
The patch is commited, so I think the bug is fixed. Feel free to reopen if the bug still occurs.