Bug 424319 - Modifier shortcut keys stop working
Summary: Modifier shortcut keys stop working
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Shortcuts and Canvas Input Settings (show other bugs)
Version: 4.3.0
Platform: Microsoft Windows Microsoft Windows
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression, triaged
: 423404 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-17 07:28 UTC by dummsaccs
Modified: 2021-02-26 12:46 UTC (History)
7 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
attachment-29636-0.html (1.18 KB, text/html)
2020-09-17 00:14 UTC, stephen
Details
attachment-18531-0.html (831 bytes, text/html)
2020-10-01 11:33 UTC, stephen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description dummsaccs 2020-07-17 07:28:18 UTC
SUMMARY
Whenever I open the app, and start working, after a while, keys like shift, space stop working. I try to drag the mouse while pressing shift to increase/decrease the brush size, it doesn't work. Not only this but, space, ctrl, shift+space, all of them don't work. And I checked but it's not a problem with the keys. If I change to a different tool, then it works for a a while but then again it stops.

STEPS TO REPRODUCE
1. Open Krita, and load a document.
2. Start working on your piece
3. Try to use pan, brush size, color picker through shortcuts.

OBSERVED RESULT
The color picker doesn't pick, the brush size isn't changed and lines get drawn, pan doesn't work.

EXPECTED RESULT


SOFTWARE/OS VERSIONS
Windows: 
macOS: 
Linux/KDE Plasma: 
(available in About System)
KDE Plasma Version: 
KDE Frameworks Version: 
Qt Version: 

ADDITIONAL INFORMATION
Comment 1 Tiar 2020-07-27 17:14:51 UTC
Is it possible that you for example switch to another program just before those keys stops working?

I cannot reproduce it on Linux and I don't remember anyone with that issue on reddit, but there are sometimes some issues with input after switching focus to another application, hence the question.
Comment 2 Tiar 2020-07-27 21:54:42 UTC
Hi, I noticed there is bug 423404 that says it only happens when they open a particular PSD file, is it possible that it also happens to you only in those circumstances?
Comment 3 Bug Janitor Service 2020-08-11 04:33:17 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 4 Halla Rempt 2020-08-24 14:16:45 UTC
*** Bug 423404 has been marked as a duplicate of this bug. ***
Comment 5 Halla Rempt 2020-08-24 14:17:38 UTC
Please provide more information

* In which language are you using Krita?
* Which keyboard layout?
* Does this happen, like we asked before, after you open a certain psd file?
Comment 6 stephen 2020-08-24 16:50:36 UTC
(In reply to Boudewijn Rempt from comment #5)
> Please provide more information
> 
> * In which language are you using Krita?
> * Which keyboard layout?
> * Does this happen, like we asked before, after you open a certain psd file?

My keyboard layout is French Azerty. 
But Krita runs in English. 
I provided a psd file to one of you for inspection.
But this bug never happened again since last time. Maybe it was fixed.
Right now, I'm using an early Krita stable build, version 4.4.0 alpha...
Comment 7 stephen 2020-09-03 18:38:43 UTC
(In reply to Boudewijn Rempt from comment #5)
> Please provide more information
> 
> * In which language are you using Krita?
> * Which keyboard layout?
> * Does this happen, like we asked before, after you open a certain psd file?

(In reply to stephen from comment #6)
> (In reply to Boudewijn Rempt from comment #5)
> > Please provide more information
> > 
> > * In which language are you using Krita?
> > * Which keyboard layout?
> > * Does this happen, like we asked before, after you open a certain psd file?
> 
> My keyboard layout is French Azerty. 
> But Krita runs in English. 
> I provided a psd file to one of you for inspection.
> But this bug never happened again since last time. Maybe it was fixed.
> Right now, I'm using an early Krita stable build, version 4.4.0 alpha...

Using Krita 4.4.0 alpha stable build(git ed74e2a), the bug started again on a random way. But all I can tell is, it happens when I switch between my Internet Browser and the application(Krita). On random occasion, all modifier keys including tool invocation shortcuts like Space, will temporarily disable themselves and there's no way to activate them back if you don't restart Krita or wait a long long time.
Comment 8 stephen 2020-09-03 18:40:56 UTC
Switching back to REPORTED. 
See Comment #7
Comment 9 Tiar 2020-09-03 18:47:16 UTC
There were some time ago lots of people reporting problems with tablet pressure after doing something like that...
Comment 10 Dmitry Kazakov 2020-09-16 19:37:22 UTC
Hi, Stephen and Dummsaccs!

Could you clarify tho things for me: 

1) When the modifiers stopped working, what did your stylus do, did it paint with the brush or just did nothing? If painted, did pressure-sensitivity work correctly in this stroke?

2) When you pressed the modifier, did the cursor change?
Comment 11 Dmitry Kazakov 2020-09-16 19:50:53 UTC
And one more question:

3) Did you use tablet or mouse? If tablet, what API you have activated in Preferences->Tablet, WinTab or WinInk?
Comment 12 stephen 2020-09-17 00:14:56 UTC
Created attachment 131710 [details]
attachment-29636-0.html

1) Pen pressure still works when it happens and you can paint with the
stylus.

2) Modifier keys do nothing when the issue occurs and no, the brush cursor
doesn't change.

3) As for the API I was using WinTab.

On Sep 16, 2020 20:50, "Dmitry Kazakov" <bugzilla_noreply@kde.org> wrote:

https://bugs.kde.org/show_bug.cgi?id=424319

--- Comment #11 from Dmitry Kazakov <dimula73@gmail.com> ---
And one more question:

3) Did you use tablet or mouse? If tablet, what API you have activated in
Preferences->Tablet, WinTab or WinInk?
Comment 13 Dmitry Kazakov 2020-09-17 07:58:27 UTC
Hi, Stephen and Dummsaccs!

From the symptoms you describe it looks like Krita gets a KeyPress event for some key and never gets a KeyRelease for it. It makes Krita think that the key is pressed forever, which blocks all actions other than painting.

If my guess is right then switching to another app and then back to Krita should exit this locked state (Krita resets its internal key-tracking state on every FocusIn event).

I have found a small bug in the key processing code, but I'm not sure it is related to this bug. Could you do some tests for me?

1) Download 'dk1-failing' package from here: https://yadi.sk/d/wO9UmqtHIs-nIw
2) Remove existing 'krita.log' file (it is placed in %LOCALAPPDATA% folder)
3) Work with the package for some time until the problem appears
4) As soon as the problem appear go to Help->Show Krita Log For Bugreports
5) Save the log into some file, e.g. 'dk1-failing.log', and attach to this bug

6) Download 'dk2-fixed' package: https://yadi.sk/d/h5F3FJ6pbBTcuA
7) Remove existing 'krita.log' file (it is placed in %LOCALAPPDATA% folder)
8) Work with the package for some time trying to reproduce the problem
9) If the problem appears, go to Help->Show Krita Log For Bugreports
10) Save the log into some file, e.g. 'dk2-fixed.log', and attach to this bug

These packages are basically Krita 4.4 Beta1, which is not yet released, but with extra logging added. I don't think this logging will affect performance in any way.
Comment 14 Dmitry Kazakov 2020-09-17 12:17:01 UTC
Btw, what tablets do you use? 

I noticed that when using Huion and switching back from Chrome (only this exact combination is affected), the first stroke is interrupted after about 0.5 sec by a spurious focus-lost event. The problem doesn't happen if I switch from any application that is not Chrome or if I use Wacom tablet. The problem doesn't appear if Krita is switched into WinInk, only WinTab is affected.
Comment 16 Dmitry Kazakov 2020-09-17 22:46:47 UTC
Git commit 040261e2bb7ede3d11359c27190a0208a949bf44 by Dmitry Kazakov.
Committed on 17/09/2020 at 22:17.
Pushed by dkazakov into branch 'krita/4.3'.

Fix mapping of Alt key on Windows

Windows' mnemonic for Alt key is rather confusing, isn't it? :)

M  +1    -1    libs/ui/input/kis_extended_modifiers_mapper.cpp

https://invent.kde.org/graphics/krita/commit/040261e2bb7ede3d11359c27190a0208a949bf44
Comment 17 Dmitry Kazakov 2020-09-22 09:19:00 UTC
Hi, Stephen and Dummsaccs!

Could you please test the packages I added in this comment? :)

https://bugs.kde.org/show_bug.cgi?id=424319#c13
Comment 18 stephen 2020-09-24 11:20:45 UTC
(In reply to Dmitry Kazakov from comment #17)
> Hi, Stephen and Dummsaccs!
> 
> Could you please test the packages I added in this comment? :)
> 
> https://bugs.kde.org/show_bug.cgi?id=424319#c13

Oh, ok.
I'll do tests.
Comment 19 Halla Rempt 2020-09-28 14:04:53 UTC
Did you manage to do the testing? This is one of the last bugs blocking our 4.4.0 release, and we haven't been able to reproduce it ourselves.
Comment 20 stephen 2020-09-29 15:23:57 UTC
(In reply to Boudewijn Rempt from comment #19)
> Did you manage to do the testing? This is one of the last bugs blocking our
> 4.4.0 release, and we haven't been able to reproduce it ourselves.

Alright. I did tests. Wasn't able to reproduce the issue. 
However, on random occasions, when I get back to the app, cursor behavior is confused with space. As a result, even without pressing space, the hand tool is like, in use, and moving the pen around leads to panning the canvas. Doesn't happen with mouse. 
When this happens, I restart a service from my tablet driver to stop it. And for a while, even after I lose focus or get krita in focus, the issue doesn't occur.

Stopping my tablet driver service doesn't fix non-responsive modifier keys though. For this one, I must either press Tab key once at least then avoid losing focus again, or restart Krita.
Comment 21 Dmitry Kazakov 2020-10-01 10:33:06 UTC
Hi, stephen!

Could you tell me, what tablet do you use?
Comment 22 stephen 2020-10-01 11:33:56 UTC
Created attachment 132045 [details]
attachment-18531-0.html

Hi Dmitry. I'm using a Huion H610 Pro.

On Oct 1, 2020 11:33, "Dmitry Kazakov" <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=424319
>
> --- Comment #21 from Dmitry Kazakov <dimula73@gmail.com> ---
> Hi, stephen!
>
> Could you tell me, what tablet do you use?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
Comment 23 Dmitry Kazakov 2020-10-05 08:40:56 UTC
Switch back to REPORTED
Comment 24 Dmitry Kazakov 2020-10-05 09:18:05 UTC
Okay, Bollebib reported a bug like that:

Tablet: yiynova 22 inch
API: WinTab
Comment 25 Bollebib 2020-10-05 14:20:25 UTC
I seem to have an issue that is similar to this one



I was told to say i have Azerty keyboard
Comment 26 Dmitry Kazakov 2020-11-27 21:32:50 UTC
Git commit 86cc68ea0db64258b3ed8e9257b5f14f59509d34 by Dmitry Kazakov.
Committed on 27/11/2020 at 21:32.
Pushed by dkazakov into branch 'master'.

Another attempt to fix the locked modifiers state on Windows

It looks like Windows drops some key events when the user presses
Windows' window manager shortcuts, e.g. Alt+Space.

Steps to reproduce:
1) Press Alt+Space, see window title menu appeared
2) Click on the canvas to hide it
3) Now Krita is in a locked state. Press Alt key to unlock it.

M  +26   -0    libs/ui/input/kis_input_manager.cpp
M  +14   -10   libs/ui/input/kis_input_manager_p.cpp
M  +1    -0    libs/ui/input/kis_input_manager_p.h
M  +20   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +14   -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/86cc68ea0db64258b3ed8e9257b5f14f59509d34
Comment 27 Dmitry Kazakov 2020-11-27 21:34:16 UTC
Git commit 59c60f7ea94a4a0d97e3c1935902285f51ba4268 by Dmitry Kazakov.
Committed on 27/11/2020 at 21:34.
Pushed by dkazakov into branch 'krita/4.3'.

Another attempt to fix the locked modifiers state on Windows

It looks like Windows drops some key events when the user presses
Windows' window manager shortcuts, e.g. Alt+Space.

Steps to reproduce:
1) Press Alt+Space, see window title menu appeared
2) Click on the canvas to hide it
3) Now Krita is in a locked state. Press Alt key to unlock it.

M  +26   -0    libs/ui/input/kis_input_manager.cpp
M  +14   -10   libs/ui/input/kis_input_manager_p.cpp
M  +1    -0    libs/ui/input/kis_input_manager_p.h
M  +20   -0    libs/ui/input/kis_shortcut_matcher.cpp
M  +14   -0    libs/ui/input/kis_shortcut_matcher.h

https://invent.kde.org/graphics/krita/commit/59c60f7ea94a4a0d97e3c1935902285f51ba4268
Comment 28 Dmitry Kazakov 2020-11-27 21:41:01 UTC
Hi, Dummsaccs, Stephen and Bollebib!

I think I have finally fixed the problem of this bug. Could you please test the new package?

This package is from my local branch:
https://yadi.sk/d/f7TRMrYAWa48lQ

And tomorrow there will be a package with what is going to become Krita 4.4.2 (you need build #950 or later):
https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/
Comment 29 Tiar 2020-12-14 00:22:55 UTC
@Dmitry can bug 428080 be a duplicate of this bug (except that it happens on Linux)? That would mean it needs a patch on Linux as well...
Comment 30 Bug Janitor Service 2020-12-29 04:34:25 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least
15 days. Please provide the requested information as soon as
possible and set the bug status as REPORTED. Due to regular bug
tracker maintenance, if the bug is still in NEEDSINFO status with
no change in 30 days the bug will be closed as RESOLVED > WORKSFORME
due to lack of needed information.

For more information about our bug triaging procedures please read the
wiki located here:
https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please
mark the bug as REPORTED so that the KDE team knows that the bug is
ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 31 stephen 2020-12-29 19:54:54 UTC
(In reply to Dmitry Kazakov from comment #28)
> Hi, Dummsaccs, Stephen and Bollebib!
> 
> I think I have finally fixed the problem of this bug. Could you please test
> the new package?
> 
> This package is from my local branch:
> https://yadi.sk/d/f7TRMrYAWa48lQ
> 
> And tomorrow there will be a package with what is going to become Krita
> 4.4.2 (you need build #950 or later):
> https://binary-factory.kde.org/job/Krita_Stable_Windows_Build/

Hello Dmitry and everyone.
So the issue still persists when I switch from browser to Krita some times(input stuck on panning).

Now, to quickly get rids of this annoying state, I've found another solution.
All you have to do is go to your browser, do a right click til context menu appears, and next, ignore the context menu and switch back to Krita.

Doing so will unlock the pan mode. I don't know why that happens tho.
Comment 32 Dmitry Kazakov 2021-01-11 07:50:14 UTC
Hi, Stephen!

What browser do you use? Is it Chrome/Chromium?

And did you test the packages I linked?
Comment 33 stephen 2021-01-13 14:17:35 UTC
(In reply to Dmitry Kazakov from comment #32)
> Hi, Stephen!
> 
> What browser do you use? Is it Chrome/Chromium?
> 
> And did you test the packages I linked?

Hi Dmitry.

So after testing the packages, it turns out that the in cursor gets locked and can't be moved anymore
Comment 34 tomtomtomreportingin 2021-01-25 18:50:03 UTC
Not sure if it's the same issue, but I can reproduce this behavior in 4.4.2 simply by hitting Ctrl + Tab. Hitting tab again or switching windows fixes it.
Comment 35 tomtomtomreportingin 2021-02-07 15:02:46 UTC
The above behavior I described only happens if you have one document open. Otherwise, it switches to another document. Perhaps it's trying to switch to a document that doesn't exist and that's causing some sort of lockup?
Comment 36 Dmitry Kazakov 2021-02-11 14:08:32 UTC
I can reproduce the Ctrl+Tab issue
Comment 37 Dmitry Kazakov 2021-02-13 13:58:24 UTC
Git commit 32da056571250a376e131ebfced58f138e4d225a by Dmitry Kazakov.
Committed on 13/02/2021 at 13:57.
Pushed by dkazakov into branch 'master'.

Fix unbalanced KeyPress/Release events in children of QMdiArea

When the user presses Ctrl+Tab, QMdiArea is supposed to switch
the active child window. When doing so, it eats the event. The
problem is that is doesn't eat the ShortcutOverride event,
which is kept unbalanced with the absent KeyRelease event.

We have to patch Qt to fix this issue

A  +43   -0    3rdparty/ext_qt/0111-Fix-unbalanced-KeyPress-Release-events-in-children-o.patch
M  +5    -0    3rdparty/ext_qt/CMakeLists.txt

https://invent.kde.org/graphics/krita/commit/32da056571250a376e131ebfced58f138e4d225a
Comment 38 Dmitry Kazakov 2021-02-13 14:06:09 UTC
Hi, Stephen and TomTomTom!

Could you please test if this package fixes the problem for you? I have fixed a bug in Qt that caused the Ctrl+click lockdown.

Windows 64(ZIP): https://disk.yandex.ru/d/amqm_kwi8_WZWQ

Please make sure that you have done a backup of your configuration and resources before testing this package, it is based on Krita 5.0, which can make your configuration incompatible with 4.4 after the first run.
Comment 39 tomtomtomreportingin 2021-02-14 22:01:26 UTC
Hi Dmitry, I was able to test your changes with the nightly appimage. I tested six cases:
Case 1: Single tabbed document, ctrl+tab, successful!
Case 2: Multiple tabbed documents, ctrl+tab, successful!
Case 3: Single tabbed document after closing other documents, ctrl+tab, successful!
Case 4: Single subwindowed document, ctrl+tab, successful!
Case 5: Multiple subwindowed documents, ctrl+tab, regressive behavior - color picker preview visually stays on previous document. Switching back to it by clicking on it sometimes leaves on the color picker invocation, but doesn't seem to have its functional effect, only visual.
Case 6: Single subwindowed document after closing other documents, ctrl+tab, successful!
Comment 40 Dmitry Kazakov 2021-02-19 12:38:10 UTC
Git commit 049d7c639d7376ab9662087a5cd79585626f54dc by Dmitry Kazakov.
Committed on 19/02/2021 at 12:34.
Pushed by dkazakov into branch 'master'.

Fix deactivation of the color picker when the user presses Ctrl+Tab

The action should be deactivated on the lost focus event. Since the
recent changes the Ctrl+Tab shortcut will be completely eaten be Qt,
so we cannot rely on it.

M  +2    -0    libs/ui/input/kis_shortcut_matcher.cpp

https://invent.kde.org/graphics/krita/commit/049d7c639d7376ab9662087a5cd79585626f54dc
Comment 41 Dmitry Kazakov 2021-02-19 12:42:25 UTC
Hi, TomTomTom!

Please check tomorrow's nightlies, the color picker bug should be fixed now :)
Comment 42 tomtomtomreportingin 2021-02-25 23:52:12 UTC
Everything seems to work fine now, from what I can tell.