https://bugs.kde.org/show_bug.cgi?id=428080
Michał Chojnowski <michoch...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |michoch...@gmail.com
--- Comment #7 from Michał Chojnowski <michoch...@gmail.com> ---
This bug is caused by
https://invent.kde.org/graphics/krita/-/commit/2472bb887d0f7d1e2605482aaa10d548f5334cdf#d37160403d7ee66fdb84263bd105c05447f5d64b_644_647.
Let's assume that `Super+1` switches to workspace 1. Here's a chronological
breakdown:
1. When the window manager starts, it sets up a key grab for `Super+1` with
XGrabKey().
2. User starts Krita on workspace 1 and goes to another workspace.
3. User presses `Super+1` to go back.
4. X11 sees the requested key combination and activates the grab. Until the
grab is deactivated, all keyboard events go to the window manager, not to
applications.
5. The window manager receives a KeyPress event for `Super+1`, recognizes it as
a shortcut, and executes the workspace switch, focusing Krita.
6. Krita receives a FocusIn event, and (due to the linked commit) simulates a
KeyPress event for `Super`, and then for `1`. They are marked as pressed in
Krita's shortcut matcher.
8. User releases `1`. The KeyRelease event goes to the window manager and is
ignored.
9. After the KeyRelease event for `1`, X11 deactivates the grab. Further
keyboard events go to Krita, because it's focused.
10. User releases `Super`.
11. Krita receives a KeyRelease event for `Super`. It is marked as unpressed in
the shortcut matcher.
12. Since the KeyRelease for `1` was eaten by the window manager, it never
comes to Krita, and the shortcut matcher indefinitely keeps `1` marked as
pressed. This breaks keyboard shortcuts handled by KisInputManager.
Refocusing the window with a mouse fixes the problem, because FocusIn events
clear the state of the shortcut matcher.
This description is true at least for i3. Other window managers may handle
shortcuts differently. In particular, if a window manager switches focus after
the shortcut is released, not pressed, then this issue doesn't happen.
My workaround is to remove the code introduced by the linked commit, since I
never make use of it anyway. I don't know how to fix this otherwise. Maybe we
could simulate the KeyPress events only if there is no active keyboard grab?
--
You are receiving this mail because:
You are watching all bug changes.
