GNOME Bugzilla – Bug 122688
modal dialog popup + drag in progress = mouse freeze
Last modified: 2006-11-06 17:19:08 UTC
I am experiencing a weird problem with nautilus. It happened once by accident, but I was able to reproduce my actions and can trigger the problem every time now. It's sort of difficult to explain... so here's what you do to make it happen: (1) open a navigation window (2) start a large delete operation that's going to fail with an error part-way through (3) start a mouse-drag (like, to select multiple files) (4) the error message from the delete pops up on top of your drag (5) the UI is basically frozen now What I mean by (5) is that you can't stop selecting the files. If you release the mouse button, the selection frame is still being dragged around. This causes you to not be able to click on the dialog box to clear it. I'm guessing the mouse-release event doesn't get through to the main window because of the modal dialog on top of it(?) Other applications are effected as well. I wasn't able to clear a dialog in GIMP (1.3.x) which I was running to attempt to take a screenshot. The only way out that I know of is alt+f2 then 'killall nautilus'. See attached screenshot.
*** Bug 122689 has been marked as a duplicate of this bug. ***
Created attachment 20074 [details] screenshot of problem
yikes. Still a problem in 2.8? Please reopen if it is.
Absolutely. See also bug 156009 Reopening.
Reassigning to GTK+.
*** Bug 165185 has been marked as a duplicate of this bug. ***
GTK+ 2.8 has the means to handle situations like this. Nautilus should pay attention to grab-broken events to fix.
Matthias: How are we supposed to react? Is this emitted for the drag source widget and we're supposed to cancel the drag in progress?
It is emitted on the grab widget, and you should react by cleaning up whatever needs cleaning up when the drag ends, and naturally, by cancelling the drag.
*** Bug 317633 has been marked as a duplicate of this bug. ***
Marking this as a blocker for 2.14.
I think we just need this: 1. A global flag saying whether a drag is in progress. This gets turned on in ::drag_begin() and ::drag_motion(), and gets turned off in ::drag_end() and ::drag_leave(). 2. All async dialogs check the flag first. These are the progress dialogs, the "error occurred during gnome_vfs_xfer_asnc()" dialogs, the auth dialogs. If a drag is in progress, the dialog gets postponed until the drag ends. 3. The open-a-subtree-on-drag-motion code needs to check for the flag. We may want to special-case file:// folders so that the subtree always opens (as file:// doesn't require auth), but don't open the subtree if the folder uses another VFS method.
*** Bug 348297 has been marked as a duplicate of this bug. ***
nautilus developers, can i expect some progress on this issue? what's the state?
moving the old gnome 2.14.x target milestone to 2.16.x. any status updates appreciated, code even more appreciated. :-)
I fixed the rubberbanding case, however the DnD case needs a gtk+ patch.
Created attachment 76091 [details] [review] Cancel outstanding drag when grab shadowed We currently look for grab-broken during the drag and cancel when we get it. We also want to look for grab-notify so that we catch grab shadows from e.g. a modal dialog popping up.
Commited to HEAD and gtk-2-10.