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 676316 - Super+F10 behaviour when no application running / when using multiple workspaces
Super+F10 behaviour when no application running / when using multiple workspaces
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
Depends on:
Blocks:
 
 
Reported: 2012-05-18 13:45 UTC by Pratyush Sahay
Modified: 2012-05-18 15:38 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
panel: Check for appMenu button's reactivity before opening (1.18 KB, patch)
2012-05-18 14:15 UTC, Florian Müllner
committed Details | Review

Description Pratyush Sahay 2012-05-18 13:45:26 UTC
The keyboard shortcut: Super+F10, seems to have been preconfigured to bring up the application menu on the panel. When no application is running, pressing this key combination still brings up the application menu with the menu option: Quit. Clicking on it naturally doesnt result in any action, thus making the menu redundant. Ideally, the menu itself shouldnt show up.

Also, having a few windows open on a workspace (say, workspace 1), and pressing this key combination on an empty workspace (say, workspace 2) and clicking on Quit in the menu that shows up, triggers a quit action for the active window on the previous workspace! Some applications do warn a user about closing a window (Firefox, gnome-terminal) when we switch back to previous workspace, while some like nautilus (even with multiple tabs open) just close without any warning.
Comment 1 Florian Müllner 2012-05-18 14:15:13 UTC
Created attachment 214319 [details] [review]
panel: Check for appMenu button's reactivity before opening

When the appMenu is not available, for instance when no windows are
open (on the current workspace), we make its actor unreactive to
"hide" it from keynav. However the menu can still be triggered
erroneously when using the corresponding keyboard shortcut, so
add a check for the actor's reactivity there as well.


(In reply to comment #0)
> Ideally, the menu itself shouldnt show up.

Right, it should *definitively* not show up - thanks for spotting this!
Comment 2 drago01 2012-05-18 14:49:35 UTC
Review of attachment 214319 [details] [review]:

Looks good.
Comment 3 drago01 2012-05-18 14:50:13 UTC
Review of attachment 214319 [details] [review]:

Actually change the patch status ...
Comment 4 Florian Müllner 2012-05-18 15:38:31 UTC
Attachment 214319 [details] pushed as 82c2f52 - panel: Check for appMenu button's reactivity before opening