GNOME Bugzilla – Bug 772914
wayland: Only suspend pointer grabs while compositor grab is active
Last modified: 2016-10-19 09:28:15 UTC
We can't cancel the grab when a compositor grab is activated (i.e. alt-tab, overview etc) because it will make things like drag -> alt-tab -> drop impossible. Before this patch, we'd end up with a drag operation state thinking its active, but with a pointer grab being reset to the default grab, potentially causing issues when the drag grab is eventually cleaned up. Note that thera are still issues with cross-compositor-grab drag-n-drop operations, such as the feedback actor not being updated since the pointer grab isn't receiving any pointer motions. This will eventually be addressed by the future ClutterGrab mechanism.
Created attachment 337684 [details] [review] wayland/pointer: Don't set focus while during compositor grab Teach the default grab about compositor grabs (i.e. display->event_route) so that it can avoid setting a pointer focus when after the compositor grab actively unset the pointer focus.
Created attachment 337685 [details] [review] wayland: Don't cancel the pointer grab on compositor grabs We shouldn't cancel the pointer grab when there is a compositor grab, since that'd break things like drag-n-drop via the overview and alt-tabs. The original reason for cancelling the pointer grab on compositor grabs was to avoid a re-entry when a compositor grab was activated while there was an active pointer constraint grab. The re-entry would happen when the compositor grab cleared the pointer focus. Clearing the focus would trigger the pointer constraint to be deactivated, which would end its grab. Ending the grab would reset the grab to the default one, which could focus the same surface again, triggering the constraint to re-enable before it finished disabling. This is now avoided because the default grab handler is now aware of compositor grabs, and won't override the cleared pointer focus until the compositor grab ends.
Review of attachment 337684 [details] [review]: looks good. commit message is a bit confusing with things like "while during" and "when after"
Review of attachment 337685 [details] [review]: makes sense, and I can now dnd through the overview but I can also release the mouse button while on the overview and the dnd doesn't get canceled
(In reply to Rui Matos from comment #4) > Review of attachment 337685 [details] [review] [review]: > > makes sense, and I can now dnd through the overview but I can also release > the mouse button while on the overview and the dnd doesn't get canceled True. I don't think that's a regression from before though. The problem is that as long as there is any composito grab, the dnd grab doesn't get any input, so it won't see the button release. Until we have something like ClutterGrab, the best thing we could o is to add a hack that checks the button count on every grab-focus vfunc call to see whether it should cancel when it would start receiving input events again.
Pushed since this improves stability and the reported issue is not a regression. Attachment 337684 [details] pushed as b50da46 - wayland/pointer: Don't set focus while during compositor grab Attachment 337685 [details] pushed as 8a7876d - wayland: Don't cancel the pointer grab on compositor grabs
(In reply to Rui Matos from comment #3) > Review of attachment 337684 [details] [review] [review]: > > looks good. commit message is a bit confusing with things like "while > during" and "when after" Sorry, noticed I didn't fix the commit message, so it ended up in the git history.