GNOME Bugzilla – Bug 736110
Rethink pointer/touch grab transfers in gnome-shell
Last modified: 2021-07-05 14:34:56 UTC
After clicking the show apps button of the dash some times in a row hides the overview. After some investigation it is the AppSwitchAction in windowManager.js gesture being activated and activating a window, which makes the overview to hide. I don't have a touch device, so not sure why is being activated.
This seems to be due to a captured-event handler being added mid-press, and consuming the button release so it's never seen by the gesture, after a third press it would think it has enough points and trigger. I could not trace yet where is the handler being added. How this grabbing behavior is implemented and used on st/gnome-shell is very much an item I would like to revisit for 3.15, right now it's too easy to leave stale data and captured-event handlers around :(. I'm attaching a patch that disables the gesture while the overview is toggled on, it makes sense to add this (it still does switch windows when the overview is visible, you just don't know which, and only if you don't select a window thumbnail afterwards), and the patch also coincidentally fixes this. But I would suggest that this bug remains open, or a new "rework grabs" one is added.
Created attachment 285530 [details] [review] windowManager: limit the "switch app" gesture to !overview.visible This gesture only makes sense to be triggered outside the overview, when dealing with application windows themselves.
Review of attachment 285530 [details] [review]: A fine workaround patch.
Comment on attachment 285530 [details] [review] windowManager: limit the "switch app" gesture to !overview.visible Attachment 285530 [details] pushed as 215eb5c - windowManager: limit the "switch app" gesture to !overview.visible
Retitiling as per comment #1. Thinking a bit more about it, what I miss the most is a mechanism similar to ::grab-notify/gtk_widget_device_is_shadowed() in GTK+, so previous grabbing actors can update to a coherent state when input is redirected somewhere else.
I'm not sure if it makes sense to add this in mutter or in gnome-shell. Think about both.
Right, I would even think Clutter, and have this triggered through clutter_input_device_sequence_grab(). It could be best for the long term to use toolkit facilities than impersonating those, and this should work for plain ClutterActors all across the hierarchy (eg. the stage, so gestures drop sequences grabbed elsewhere).
The issue with that is that we already have a grab system in mutter with MetaEventRoute, etc., and mutter already pokes behind Clutter's back for lots of stuff. If you want to rewrite all of that to use a new grab infrastructure in Clutter, hey, more power to you I guess.
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.