GNOME Bugzilla – Bug 694837
gnome-shell start-up animations break overview
Last modified: 2013-03-04 16:59:06 UTC
If I launch the overview via <super>, during the startup animation, I end up with a.) in overview with a stuck grab (mouse interaction with panel works), that I can't get out of (via keyboard). b.) Layout of overview windows is way out of whack, shifted a long way towards bottom right corner of primary monitor. Btw this only affects the primary monitor, secondary monitors display correctly
I can't reproduce this
I can reproduce it quite reliably. To get the broken layout, I need to press <super> and activate overview, just before the actual animation starts. To get the stuck grab, I can press <super> and activate overview, any time before the animation has ended.
do the patches in bug 694321 help? ( in particular attachment 237926 [details] [review] )
Attachment 237926 [details] by itself didnt seem to help at all, however with all patches applied, <super> keypress no longer seems to register before the animation starts, thus can't hit the broken layout. Hitting <super> during the animation still results in a stuck grab though.
Created attachment 237990 [details] [review] main: don't hook up overview keybinding until after startup Toggling the overview during the startup animation reportedly causes stuck grab and other odd behavior. There's no reason to handle toggling the overview during this time anyway. This commit defers that handling until after startup.
Review of attachment 237990 [details] [review]: While this looks good and should solve the problem for the overview key, I wonder whether it makes more sense to just disable keybindings altogether during the animation - it shouldn't be much more code, just initialize Main.keybindingMode to Shell.KeyBindingMode.NONE and make sure it is set to Shell.KeyBindingMode.NORMAL once the animation is done ...
(In reply to comment #6) > Review of attachment 237990 [details] [review]: > > While this looks good and should solve the problem for the overview key, I > wonder whether it makes more sense to just disable keybindings altogether > during the animation - it shouldn't be much more code, just initialize > Main.keybindingMode to Shell.KeyBindingMode.NONE and make sure it is set to > Shell.KeyBindingMode.NORMAL once the animation is done ... sounds better
Created attachment 238011 [details] [review] keybindings: filter overlay key even when not-modal mutter currently only filters the overlay key through the shell when there is a grab operation and that grab operation belongs to the shell (because the shell is pushModal'd). This means the shell can't filter out overlay key press events events at startup (since the shell isn't normally modal). This commit changes the code to always run the shell filtering code, even when the shell is not modal.
Created attachment 238012 [details] [review] main: don't hook up overview keybinding until after startup Toggling the overview during the startup animation reportedly causes stuck grab and other odd behavior. There's no reason to handle toggling the overview during this time anyway. This commit defers that handling until after startup.
Review of attachment 238011 [details] [review]: Ugh, apparently I forgot to change that when we changed the filtering of "normal" keybindings to apply always rather than only during compositor grabs. So even independently from this bug, we should do this.
Review of attachment 238012 [details] [review]: LGTM ::: js/ui/main.js @@ +206,3 @@ + layoutManager.connect('startup-complete', function() { + if (keybindingMode == Shell.KeyBindingMode.NONE) { + keybindingMode = Shell.KeyBindingMode.NORMAL; This is for modes like gdm? Otherwise I don't see what would change keybinding mode during startup (not that the additional test would hurt though ...)
(In reply to comment #11) > Review of attachment 238012 [details] [review]: > > LGTM > > ::: js/ui/main.js > @@ +206,3 @@ > + layoutManager.connect('startup-complete', function() { > + if (keybindingMode == Shell.KeyBindingMode.NONE) > { > + keybindingMode = > Shell.KeyBindingMode.NORMAL; > > This is for modes like gdm? Otherwise I don't see what would change keybinding > mode during startup (not that the additional test would hurt though ...) Right, the login screen is shown before the startup is complete and we don't want to overwrite any pushModal that happens in that path.
Comment on attachment 238011 [details] [review] keybindings: filter overlay key even when not-modal Attachment 238011 [details] pushed as 377e2ed - keybindings: filter overlay key even when not-modal
Attachment 238012 [details] pushed as cd37e29 - main: don't hook up overview keybinding until after startup