GNOME Bugzilla – Bug 635278
dnd: call ungrabEvents when the drag actor is destroyed
Last modified: 2010-11-19 20:11:09 UTC
If the drag actor is destroyed (possibly as part of a drag target accepting it), we were not calling ungrabEvents, meaning the mouse/keyboard remained grabbed until you clicked somewhere to cancel it. This fixes that without trying to improve the extremely confusing control flow...
Created attachment 174855 [details] [review] dnd: call ungrabEvents when the drag actor is destroyed
Review of attachment 174855 [details] [review]: Wow, that code flow is confusing - "that patch can't be right, the drag isn't getting cancelled... oh wait" Looks fine to me, I'd make the commit message "dnd: call ungrabEvents _even_ when the drag actor is destroyed"
(In reply to comment #1) > Created an attachment (id=174855) [details] [review] > dnd: call ungrabEvents when the drag actor is destroyed Hmm, when an actor is destroyed during a drag operation, the mouse button is still pressed. So releasing the grab at that point means that the actor which happens to be underneath the pointer when the button is released processes the event, right?
Created attachment 174864 [details] [review] dnd: fix a case where ungrabEvents wasn't being called take 2. This only calls ungrabEvents from _cancelDrag if (a) the actor was destroyed, and (b) the mouse button is not pressed, which should limit it to just this case
Review of attachment 174864 [details] [review]: sure. (generally I think things only need to be reactive to press/release not isolated release. (See the bug I just filed about clicking off menus.)
Attachment 174864 [details] pushed as b7c1400 - dnd: fix a case where ungrabEvents wasn't being called