I've found something else interesting. If I press Shift+Mod4+Left (or Right) in that order, the action works; however, Mod4+Shift+Left (or Right) doesn't. Same for all combinations that use Shift.

I additionally tried combinations like Mod4+L to lock the screen, but as Mod4+U, it didn't work. Curiously, Mod4+T to launch a terminal works, and setting Mod4+L to the launch terminal action also works. On the other hand, Ctrl+Alt+L works for locking the screen, it's just the combination of Mod4+letter with this action that fails under Gnome-Shell (it does work with Compiz in the Ubuntu set-up I described).

Same problem. I've also found something else interesting: If I click Windows Key to enter the overview and then click and hold Windows Key, I can use the shortcuts.

Aditionally, even if the shortcut is a combination of Mod4+letter, you can first click and hold Shift, then click and hold Mod4, then release Shift, then click letter. This way, it works. Shift can be substituted by any other modifier.

It looks like the Windows key is not recognized as a modifier key unless: 1) you are in the overview; 2) you click and hold another modifier key first.

Also, Windows key has a diferent behavior when entering and exiting the overview: overview is activated on key release, but it exist as soon as I hit the key again (not when I release it). This is a different issue, but might me related.

Is the bug being worked on? This is a very irritating problem. I have faced exactly the same problem as the previous users have mentioned.

This is probably the same thing as #649389.

*** Bug 649389 has been marked as a duplicate of this bug. ***

Seems that one can disable or change the overlay-key the workspace overview is bound to through the gconf key /apps/mutter/general/overlay_key. I changed it from Super_L to F1 as a workaround and now can use Win key shortcuts without any interference from gnome-shell. Interestingly F1 only works to enable the workspace overview not to disable it, which still is done with the Win key.

I suspect this is related to bug 603778.

In general, keybindings whose only modifier is Mod4, listed in the "Window Manager" section of the Shortcuts tab of the Keyboard applet in gnome-control-center do not work unless you clear out /apps/mutter/general/overlay_key, then log out and log back in.

Keybindings in other sections of the Shortcuts tab work fine, keybindings in the "Window Manager" tab work fine if they have at least one non-Mod4 modifier, and everything works if you clear out that gconf key (except then you can't access the Activities screen by tapping the windows key - but you can always set the "Show the panel's main menu" binding to something, which has the same effect.

Mod4+Tab doesn't work for switching windows, but that's Bug 645200.

Okay. I've been digging into this for a little bit and I think I know what's going on. I've not had much mutter / X experience, but it seems plausible (and my patch works, so it can't be too wrong ;))

It looks like when event_callback is called with any key events that come after the super keypress event, the x window related to the event is being set to the root X window. There is no metacity window for the root X window, so all keybindings that operate on a window will not match (this is why e.g minimize won't work, but going to another workspace does).

I have no idea how event_callback gets the relevant window for an event. My guess is that when the windows (overlay) key is pressed, mutter takes a grab using the root window, so further keypresses are associated with the root window instead of the actual focused window. When you press alt before super (for example), the overlay key grab is never triggered which is why you don't see this bug.

Created attachment 190115 [details] [review]
implement workaround for mutter

This patch modifies event_callback to assume that any keypress event involving the super key is actually attached to the current focused window.

Possible problems:
 - super is hardcoded (it won't reflect changes to the overlay_key setting). I tried to do this better, but couldn't figure out how to convert a keycode / sym to a modifier mask.
 - assuming the focused window is surely wrong in some cases. But the consequences seem fairly harmless, and the existing breakage is much more disruptive (to me at least).

Created attachment 191551 [details] [review]
Improve handling of <Super>key combinations

In general, I think using the focus window in place of the window delivered
to the event is very accurate... after all, the focus window determines
which window events are delivered to, and hence which passive key grabs
are triggered.

But I wanted to try to doing it a slightly different way and use XAllowEvents()
to "replay" the event back to normal event delivery. We wanted to do this
initially when we added the overlay key handing, but didn't find the time.

It doesn't work *great* - it doesn't allow other apps to have global keybindings
on <Super>key - because of the way XAllowEvents() is defined, but does in my
testing seem to properly make <Super>key combinations work for global and
per-window Mutter bindings and has a slight advantage of also doing delivery
normal (non-grabbed) key delivery to applications.

Testing would be appreciated.

====

When we get a press of the overlay key, and then another key is pressed,
first try to handle the combination as a global keybinding. If that fails,
call XAllowEvents(..., ReplayKeyboard, ...) to let it be handled by
our per-window keybindings or by the application.

This requires restructuring things to call XAllowEvents a bit later
so we can pass the right mode.

Patch works as advertised for me, although I'm concerned about not allowing other apps to have global keybindings - that doesn't seem so great, but I'm not sure how common that is in practice.

*** Bug 603778 has been marked as a duplicate of this bug. ***

Comment on attachment 191551 [details] [review]
Improve handling of <Super>key combinations

seems to work.

I thought at first that you could use ReplayEvent after getting the Super KeyPress, and then that would let other global grabs work. But I guess XGrabKey only grabs KeyPress, not KeyRelease, so if you release the grab you never see the Super KeyRelease and things get all messed up.

so, I guess this is the best we can do

OK, going to push this - we'll see if any problems pop up in practice.

Attachment 191551 [details] pushed as 12f71c9 - Improve handling of <Super>key combinations

Something isn't quite right here, it seems.

It's difficult to reproduce, but this is what I'm seeing:

With my `minimize` shortcut is set to mod4+m, I do the following:

 - have window1 and window2 open
 - click window1
 - *programmatically* activate window2, without clicking it or moving the mouse
 - press mod4+m

I would expect window2 to minimize, but window1 does! I've tried with and without focus-follows-mouse, both exhibit the same behaviour).

I can do this easily enough using shellshape[1] since it adds keyboard shortcuts for cycling the active window directly, but I can't reproduce with the alt-tab dialog (possibly since it causes many more x events that obscure the bug). The method used in shellshape to focus a window is imports.ui.main.activateWindow(metaWindow). I tried to reproduce this in looking glass, but again I suspect the closing of lg itself causes additional things to happen and hide the bug. If there was a setTimeout() I think I could reproduce it, but I couldn't find setTimeout mechanism in either gjs or gnome-shell.

Note that if I change my minimize shortcut to be ctrl+alt+m or something not involving mod4, everything works as expected (thus why I'm assuming it is related to this patch).

I didn't have this problem with my original patch, so I'm thinking there's a difference in how the active window is determined for replaying the event?

Should I reopen this bug?

[1]: http://gfxmonk.net/shellshape/

(In reply to comment #15)

> I didn't have this problem with my original patch, so I'm thinking there's a
> difference in how the active window is determined for replaying the event?
> 
> Should I reopen this bug?

 - Completely non-obvious to me why this would happen
 - Mainloop.timeout_add()
 - I'd prefer it if you filed a new bug

Thanks Owen.

It wasn't exactly happening under the conditions I thought, I've now managed to reproduce it more sensibly without using timeouts. I've raised a new bug: https://bugzilla.gnome.org/show_bug.cgi?id=655615 - I still can't figure out why the code would be causing it, but perhaps you can?

(In reply to comment #9)
> Created an attachment (id=190115) [details] [review]
> implement workaround for mutter
> 
> This patch modifies event_callback to assume that any keypress event involving
> the super key is actually attached to the current focused window.


Hi Tim,

Attaching to current focused window, solves only the shortcuts related to window manager, but other shortcuts like custom shortcuts, do not work with super key.

Except Window manager shortcuts, like minimize, move, shade, etc., all other shortcuts still has this bug (unable to use super key propely).

All other Shortcuts with superkey+key:(All settings->keyboard->shortcuts)

1. Launchers
2. Navigation (only window related shortcuts work as expert like move)
3. Screenshot
4. Sound and Media
5. System
6. Universal Access
7. Windows [Works as expected]
8. Custom Shortcuts

So, I believe this bug is not fixed, as it does not fix the issues with 7 out of 8 shortcut sets. Only (7.) Windows and (2.) Navigation shortcuts (partially), work. please see bug 659899

thanks.

This bug was just about the fact that some mutter shortcuts could use Super and others couldn't. The fact that gnome-shell steals Super so that no one other than the shell can use it is... some other bug. Can't find it right now.

*** Bug 661827 has been marked as a duplicate of this bug. ***

I'm not sure this is fixed well enough.  I have Windows+L set to lock my screen.  If I focus gnome-terminal and press Windows+L, then an 'L' gets typed.  If I focus a Firefox text box and press Windows+L, the textbox blinks weirdly and no 'L' is typed.  If I hold the Windows key and press L twice, the screen locks.

 had this same problem after upgrading. The dconf path is org/gnome/settings-daemon/plugins/media-keys. The predefined shortcuts live there. Custom shortcuts live further down under custom-keybindings/custom0 (or custom1, and so on).

Changing <Super> to <Mod4> in my shortcuts fixed the problem.
http://superuser.com/questions/415675/gnome-shell-3-4-and-a-super-key-related-shortcut