After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 694837 - gnome-shell start-up animations break overview
gnome-shell start-up animations break overview
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: overview
3.7.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2013-02-28 03:07 UTC by darkxst
Modified: 2013-03-04 16:59 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
main: don't hook up overview keybinding until after startup (4.07 KB, patch)
2013-03-04 14:08 UTC, Ray Strode [halfline]
reviewed Details | Review
keybindings: filter overlay key even when not-modal (3.69 KB, patch)
2013-03-04 16:30 UTC, Ray Strode [halfline]
committed Details | Review
main: don't hook up overview keybinding until after startup (5.40 KB, patch)
2013-03-04 16:30 UTC, Ray Strode [halfline]
committed Details | Review

Description darkxst 2013-02-28 03:07:46 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
Comment 1 Matthias Clasen 2013-03-01 18:19:50 UTC
I can't reproduce this
Comment 2 darkxst 2013-03-02 20:48:04 UTC
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.
Comment 3 Ray Strode [halfline] 2013-03-04 06:03:42 UTC
do the patches in bug 694321 help?

( in particular attachment 237926 [details] [review] )
Comment 4 darkxst 2013-03-04 06:42:07 UTC
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.
Comment 5 Ray Strode [halfline] 2013-03-04 14:08:52 UTC
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.
Comment 6 Florian Müllner 2013-03-04 14:39:22 UTC
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 ...
Comment 7 Ray Strode [halfline] 2013-03-04 15:45:27 UTC
(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
Comment 8 Ray Strode [halfline] 2013-03-04 16:30:20 UTC
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.
Comment 9 Ray Strode [halfline] 2013-03-04 16:30:49 UTC
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.
Comment 10 Florian Müllner 2013-03-04 16:42:53 UTC
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.
Comment 11 Florian Müllner 2013-03-04 16:45:02 UTC
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 ...)
Comment 12 Ray Strode [halfline] 2013-03-04 16:56:03 UTC
(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 13 Ray Strode [halfline] 2013-03-04 16:57:29 UTC
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
Comment 14 Ray Strode [halfline] 2013-03-04 16:59:03 UTC
Attachment 238012 [details] pushed as cd37e29 - main: don't hook up overview keybinding until after startup