Bug 428080 - Krita does not handle focus gain properly when switching to its workspace using a keyboard shortcut
Summary: Krita does not handle focus gain properly when switching to its workspace usi...
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: General (show other bugs)
Version: 4.4.0
Platform: unspecified Linux
: NOR minor
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-10-22 00:16 UTC by Benny Aguilera
Modified: 2022-11-10 13:33 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
MATE desktop workspace switching shortcuts (16.33 KB, image/png)
2021-01-12 11:45 UTC, Ahab Greybeard
Details
Video of the problem as it happens (990.18 KB, video/mp4)
2021-01-12 11:45 UTC, Ahab Greybeard
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Benny Aguilera 2020-10-22 00:16:58 UTC
If I switch to a workspace with Krita open using a keyboard shortcut in i3, some functionality breaks until I refocus Krita using a mouse action, restarting i3 in place, or some similar refocus action. Some things that stop working are: 4 and 6 keys to rotate the canvas, shift-drag to resize the brush, and ctrl-click to pick colors.

The Krita windows is definitely focused, and other actions such as Ctrl-Z and drawing still work properly. I am guessing the issue is related to the canvas widget itself not receiving a focus event when Krita is focused using a keyboard-shortcut workspace-switch (alt-tab doesn't cause the issue for me on XFCE, so it has to be a workspace switch), and therefore not receiving keyboard events.

The issue also occurs for me on XFCE, and another user confirms it occurs similarly on their MATE desktop. Previous discussion on krita-artists.org here: https://krita-artists.org/t/cetrain-key-combinations-dont-work-after-switching-workspace-to-krita-linux/13001

STEPS TO REPRODUCE
1. Open Krita on workspace A
2. Switch to workspace B
3. Switch back to workspace A using a keyboard shortcut

OBSERVED RESULT
Shift-drag does not change brush size, ctrl-click does not pick color, and 4 and 6 keys do not rotate the canvas.

EXPECTED RESULT
All actions work as if Krita had been focused using a mouse

SOFTWARE/OS VERSIONS
Arch Linux
KDE Frameworks Version: n/a
Qt Version: 5.15
Krita: 4.4.0
Comment 1 Ahab Greybeard 2020-10-22 11:25:11 UTC
Summarising my observations as reported in the OP linked forum post, as noted for Debian 10 with the MATE desktop environment using the krita 4.4.0 appimage.
It also happens with the 4.2.9, 4.3.0 and the Oct 21 4.4.1 alpha (git d798711) appimages:

This happens if desktop workspace selection or switching is done by a keyboard shortcut that uses the Ctrl, Shift or Alt keys (or combination of them).

It's noticeable that with a Ctrl+ shortcut, the colour picker appears permanently on the canvas but painting does happen.
With a Shift+ shortcut, trying to paint on the canvas results in brush size variation.
With an Alt+ shortcut, painting does happen but if you click-hold on the titlebar then you get the hand (pan) icon.

With all of them, the 4 and 5 canvas rotation keys don't work.
All this is associated with Canvas Input Settings key actions.
The ways to recover from the situation are:
Click on the main titlebar. Click on a Toolbox icon. Press the Tab key.
These problems only happen if you're using a painting tool.

A similar looking problem has been reported with Windows 10 in the same forum:
https://krita-artists.org/t/4-3-beta-1-certain-keyboard-shortcuts-not-working/7027
Comment 2 Dmitry Kazakov 2021-01-11 15:20:07 UTC
Hi, Ahab!

Could you please make some video recording of the problem? I have tried Linux Mint MATE 20.04 live-usb and I couldn't reproduce the problem :(
Comment 3 Ahab Greybeard 2021-01-12 11:45:19 UTC
Created attachment 134771 [details]
MATE desktop workspace switching shortcuts

Hi Dimitry,

I attach a screenshot, 'Workspace-Switching .png', of the workspace switching keyboard shortcuts.
The switch to workspace-n shortcuts do not show a problem. It's only the switch to the left/right shortcuts that have the problem.
As you can see, I have a Shift+ shortcut for switch to the left and  Ctrl+ shortcut for switch to the right.

The attached video, 'Ctrl+ and Shift+ Keys Switch Workspace.mp4', shows the problem happening.
Use of the Ctrl+F9 shortcut seems to put a permanent Ctrl press in action until a Toolbox icon (or the title bar) is clicked.
Use of the Shift+F8 shortcut seems to put a permanent Shift press in operation until the titlebar (or a Toolbox icon) is clicked.

It may depend on which desktop enviroment is used and it may need to be installed instead of being a live-usb.
Comment 4 Ahab Greybeard 2021-01-12 11:45:56 UTC
Created attachment 134773 [details]
Video of the problem as it happens
Comment 5 Ahab Greybeard 2021-01-12 12:09:34 UTC
I've just tried it with installed Ubuntu 20.04 from last year and that has the same problem.
Comment 6 leiserfg+krita 2021-02-15 16:15:56 UTC
The same happens when using bspmwm, but it works fine if I use a key release instead of a keypress shortcut, I guess Krita is getting the focus, and then the key release event that follows the keypress and is having problems with that.
Comment 7 Michał Chojnowski 2021-08-01 23:25:05 UTC
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?
Comment 8 Shad Amethyst 2022-05-21 09:14:55 UTC
It seems like pressing the TAB key does not recover from the glitched state anymore, which makes this bug much more noticeable in my experience.

Is there any fix for the issue in sight, besides Michał's solution?
Comment 9 DO 2022-05-28 17:30:36 UTC
This is so annoying! How come Krita is literally the only program with this issue? Can this be fixed already pretty please?
Comment 10 Bug Janitor Service 2022-11-04 07:19:08 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1635
Comment 11 Bug Janitor Service 2022-11-09 16:23:09 UTC
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/1638
Comment 12 Dmitry Kazakov 2022-11-09 16:47:42 UTC
Hi, all!

Could you please check this AppImage package and see if it still has the problem? I think I have managed to fix it:

https://invent.kde.org/graphics/krita/-/merge_requests/1638#note_559734
Comment 13 Dmitry Kazakov 2022-11-10 13:33:03 UTC
Git commit 4a5a58ba22b2cd5f08475707326bacfbde28ae18 by Dmitry Kazakov.
Committed on 10/11/2022 at 13:32.
Pushed by dkazakov into branch 'master'.

Fix shortcuts issue when changing workspaces on Linux (X11)

It looks like X11 and Qt have some differences in how they
upderstand Windows and Alt keys.

X11: Windows -> Super; Alt -> Meta/Alt;
Qt:  Windows -> Meta;  Alt -> Alt;

We should properly handle that for our KisExtendedModifiersMapper.

M  +31   -7    libs/ui/input/kis_extended_modifiers_mapper.cpp

https://invent.kde.org/graphics/krita/commit/4a5a58ba22b2cd5f08475707326bacfbde28ae18