GNOME Bugzilla – Bug 655615
Window-based keybindings using mod4 get delivered to the wrong window
Last modified: 2018-02-01 09:59:28 UTC
When you do the following: - use a mond4+<something> keybinding, but _keep_ mod4 held down afterwards - change window focus - use another mod4+<something> keybinding The second keyboard shortcut will get delivered to the original window, instead of the currently active window. Exact steps to reproduce: 1) setup: - bind mod4+a to raise/lower - bind mod4+m to minimize 2) open 2 windows (I'll call the first window opened "A" and the second "B") 3) focus window "A" by clicking it 4) hold down <super>, press and release the <a> key (but keep holding <super>) 5) click on window "B" to activate it 6) press <m> Result: window "A" gets minimised, instead of "B". Workaround: The bug doesn't seem to occur if <super> is released and pressed again before pressing <m>.
This is related to bug 624869 (as it allowed super-based keybindings to work at all), so only happens on versions of mutter that include the fix for that issue (commit 12f71c9795e21cefd0faf1d98327d2139172ae71on git master).
>The second keyboard shortcut will get delivered to the original window, instead of the currently active window. Remember you made the patch to attach super key to the current focus window so that mod4+m or mod4+n key works properly. Please try to find a way with which all sets of shorcuts could work not just window management. "the super key is actually attached to the current focused window." So when you are shifting the focus to a new/other window using mouse click, the super key binding is not shifted. Hence this bug. https://bugzilla.gnome.org/show_bug.cgi?id=624869#c18 thanks.
Asif: What are you asking for? The bug you mentioned was not (ultimately) fixed by my patch, you seem to be talking about something unrelated to this bug. (FWIW, the patch I submitted for bug 624869 *doesn't* have the problem described here.)
(In reply to comment #3) > Asif: What are you asking for? The bug you mentioned was not (ultimately) fixed > by my patch, you seem to be talking about something unrelated to this bug. based on your words https://bugzilla.gnome.org/show_bug.cgi?id=624869#c9 Tim, I am not asking anything but hinting that the patch tied the super key to the existing active window, so when using click we switch to any other inactive window, the super key remain bound to the previous active window; because of this binding of super key to the (first) active window, switching (the focus) to other window using mouse, etc., without releasing the super key is causing this bug.
Okay. I take your point, that might well be an explanation for why this is happening. But I want to make clear that the attachment (of mine) that you linked to *was never accepted*, so the description of how it works is irrelevant to the current state of mutter. In fact, the patch link to does _not_ exhibit this bug, so relating this bug to behaviour I described in that patch makes no sense.
Is this about the fact that Rhythmbox sometimes gets play/pause media-keys even though Totem is focused and full screen? Happens sometimes and then I can't get the media-keys delivered to Totem so I have to close Rhythmbox (or close Totem if it's the other way around).
@Alex: I doubt it, pretty sure multimedia keys are handled entirely separately - this bug relates only to keybindings that use <super> (the windows key).
The issue described in the "exact steps to reproduce" does not reproduce anymore.