Bug 391350 - Shortcuts: Alt and Shift modifiers is not handled correctly
Summary: Shortcuts: Alt and Shift modifiers is not handled correctly
Status: RESOLVED NOT A BUG
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.12.2
Platform: Neon Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-03-03 20:00 UTC by Tore Havn
Modified: 2018-03-03 20:39 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tore Havn 2018-03-03 20:00:34 UTC
It seems the Alt+Shift modifiers do not work correctly together when using the Tab key to walk through windows. I intiially assumed it was a hardware bug (recently got a new laptop), but I have finally been able to get some details of what is happening.

1.
I also have Alt+Shift set to walk through keyboard layouts. Alt+Shift+Tab is never triggered because KWin has already triggered on Alt+Shift being pressed. Disabling Alt+Shift to walk through keyboard layouts made Alt+Shift+Tab function again.

The correct behaviour should be that Alt+Shift should only be triggerd when those keys are released, and while just being pressed and held should function as modifiers waiting for the next key to be pressed.

2.
A similar thing happens when cycling through tabs in applications.

2.1 Firefox
Ctrl+Tab will cycle through tabs, and works as it should. Ctrl+Shift+Tab however, does not work. Holding Ctrl+Shift and hiting Tab appears to do nothing. Continuing to hold Ctrl+Shift and hiting Tab again will bring the focus to the address bar.

To correctly reverse cycle through tabs in Firefox, it is necessary to hold Ctrl and hit Tab, to start the tab cycling process. By continuing to hold Ctrl and now also holding Shift, it is possible to hit Tab to reverse cycle through the tab list.

2.2 Kate
Holding Ctrl and hiting Tab will cycle through the open documents, as it should. Holding Ctrl+Shift and hiting Tab, however, will start by cycling one document forward, and then function as reverse cycling through documents.

3.
While experimenting with KWin's shortcut settings in System Settings, I noticed a funny behaviour when trying to set a custom keyboard shortcut:

First pressing and holding Alt, and then pressing and holding Shift, will display the shortcut as "Alt+Shift+...". A key combo like Alt+Shift+Tab can then be set by hiting Tab.

However, by first pressing and holding Shift, and then pressing and holding Alt, will display the shortcut as "Meta+Shift+..."! By hiting Tab it will change to Alt+Shift+Tab again and work as before.

I don't know what is happening there, but I suspect there might be some bug in the code which modifies Alt to appear as Meta. I'm including this here in case it is related to the Alt+Shift bug. Utilising the Meta key in a combination seems to make all three appear ("Meta+Alt+Shift+...").

4.
After looking through the bug tracker, I found several open, unconfirmed bugs which I suspect are other symptoms of this bug:

- Alt + Shfit + <num> shortcut bug (2018) https://bugs.kde.org/show_bug.cgi?id=391056

* kwin takes control over shortcut input and does not allow for "unshifting" (2016) https://bugs.kde.org/show_bug.cgi?id=359206

- Keyboard layout switching ignores settings, sometimes it does not work at all. (2016) https://bugs.kde.org/show_bug.cgi?id=370734

- Custom Alt+` shortcut brings up task switcher, but does not walk through applications (2016) https://bugs.kde.org/show_bug.cgi?id=359141

- inconsistent behavior with alt+7 (2016) https://bugs.kde.org/show_bug.cgi?id=365255

- Impossible to use AltGr as modifier (2016) https://bugs.kde.org/show_bug.cgi?id=359146

- Remapping Num Lock with xmodmap breaks all Alt+* key shortcuts in KDE! O_OOO (2015-2016) https://bugs.kde.org/show_bug.cgi?id=345816

- Shortcuts bound to F keys ignore state of ISO_Level3_Shift (2015) https://bugs.kde.org/show_bug.cgi?id=357127

- Keyboard input shortcut keys do not work (2015) https://bugs.kde.org/show_bug.cgi?id=348456

- Broken canvas input shortcut naming when pressing keys used to switch keyboard layouts (2014-2017, Confirmed) https://bugs.kde.org/show_bug.cgi?id=333431

- when connecting to a remote host, some modifier key (shift, or alt) is permanently pressed (2014-2016) https://bugs.kde.org/show_bug.cgi?id=329951

- Ambigous shortcut detected with pressing Ctrl+Shift+w (2013-2017, Confirmed) https://bugs.kde.org/show_bug.cgi?id=319172

- Keyboard shortcuts doesn't work if non-english keyboard layout is set before english one (2012-2018, Confirmed) https://bugs.kde.org/show_bug.cgi?id=309193

- custom shortcuts: send keyboard input does not work for keys requiring AltGr (2012-2018) https://bugs.kde.org/show_bug.cgi?id=295633

- Walk Through Windows (Reverse) does not work (2012-2017, Kde4+5) https://bugs.kde.org/show_bug.cgi?id=294249

- Unsupported Key message when adding a custom Alt+Shift+<key> shortcut (2012-2013) https://bugs.kde.org/show_bug.cgi?id=294245

- Alt-Tab menu cannot use Alt-Shift-Tab for going back through the list of windows? (2008-2015, Fixed) https://bugs.kde.org/show_bug.cgi?id=174142

- some keyboard shortcuts don't work (2008, To be closed) https://bugs.kde.org/show_bug.cgi?id=159063


5.
Technical info:
OS: KDE neon 5.12
Plasma: 5.12.2
Frameworks: 5.43
Qt: 5.10.0
Occurs on both X11 and Wayland

6.
Further thoughts:
The keyboard shortcut to walk through windows in reverse is listed as "Alt+Shift+Backtab" in System Settings. Shouldn't this just be "Alt+Shift+Tab"? Is there a translation between "Shift+Tab" and "Backtab" somewhere in the code?

After having read lots of these bug reports and the comments in them, I have a hunch that there is a problem with how modifier keys are handled in the code. Somehow there is some mixup between KeyPress, KeyRelease, and the different modifier checks. Or a bug in Qt itself. There was a lot to go through though, and I've never work with Qt, so I might very well have missed something as well.
Comment 1 Tore Havn 2018-03-03 20:02:34 UTC
Added Thomas Lübking to this, as it seems from the other bug reports that he may have a better idea of what's going on. :)
Comment 2 Thomas Lübking 2018-03-03 20:34:38 UTC
Thomas didn't use KDE for over 3 years...


Anyway, the actual bug is correctly identified and not at all related to kwin (and only to a minor extent to kglobalaccel):
"Alt+Shift should only be triggerd when those keys are released"

Qt (and KDE) fires shortcuts on key presses (at least that's what it used to be) and this also prominently blocked the usage of the meta key as menu trigger (unless you had a specific shortcut daemon for this function running and iirc this specific feature has recently been somehow included in kglobalaccel??)

The only solution is to make (all) global shortcuts different from local ones (to fire on release)

Kate & Firefox are client specific issues and totally unrelated - firefox isn't even a Qt client.

No idea about the ALt+Shift/Meta+Shift confusion, sounds like a GUI (only) bug.

Shift+Backtab is somehow a tautology, Shift+Tab is Backtab - this constantly causes bugs in the symbol handling, but as long as it works, "Shift+Backtab" is probably the least ambigious declaration.
Comment 3 Martin Flöser 2018-03-03 20:39:32 UTC
This is not a bug in KWin, but just incorrect configuration. You cannot use a subpart of a shortcut for keyboard layout switching. That's a limitation of X server and totally outside the control of our software stack.