Bug 438784

Summary: Panning and zooming bug in Krita
Product: [Applications] krita Reporter: chris <christopher.oduro7>
Component: Shortcuts and Canvas Input SettingsAssignee: Dmitry Kazakov <dimula73>
Status: RESOLVED FIXED    
Severity: normal CC: ahab.greybeard, ale97clas, alvin, aptckbt.yjfxx, dimula73, halla, hyetou, kjartan, ss93078, tgdev001, tusooa
Priority: NOR    
Version: 4.4.5   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description chris 2021-06-17 01:25:57 UTC
SUMMARY
Krita will occasionally stop recognizing that spacebar and ctrl are held down when panning and zooming around the canvas.

STEPS TO REPRODUCE
1. hold down spacebar to pan or spacebar and ctrl to zoom
2. pan and/or zoom with tablet stylus 

OBSERVED RESULT
Krita will occasionally stop recognizing that spacebar and ctrl are held down when panning and zooming around the canvas. this results in the last selected tool being activated (in my case, usually the brush tool).

EXPECTED RESULT
Panning and zooming should not stop working when spacebar and ctrl are held down.

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

ADDITIONAL INFORMATION

Log viewer docker output:

WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier)
     d->matcher.debugPressedKeys() = QVector()
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(ControlModifier)
     d->matcher.debugPressedKeys() = QVector()
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
Comment 1 tusooa 2021-06-17 02:46:54 UTC
Can't reproduce on 4.4.3, Gentoo Linux.
Comment 2 Ahab Greybeard 2021-07-24 07:39:27 UTC
This is discussed in more detail here:
https://krita-artists.org/t/krita-is-dropping-keyboard-inputs-or-its-something-else/26585
and here:
https://krita-artists.org/t/unresponsive-keyboard-input-once-again/26639

With the 4.4.5 appimage on Debian 10, I can't reproduce this after lots of key mashing of the Ctrl or Shift keys, with the Space key held down.

I can reproduce it on Windows 10 with the 4.4.5 installation and the July 23 5.0.0-prealpha (git  73473a8d27) portable .zip.

Rapidly mashing the Ctrl/Shift key while the Space key is held down at the same time as making swipes across the tablet surface with a stylus will induce the condition.
It doesn't happen if the stylus is not used to make swipes.
I can't induce it when using the mouse and that may be because I can't operate and use the mouse fast enough.

Log viewer output:
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Shift)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Shift)
WARNING: modifiers state became inconsistent! Trying to fix that...
     inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier)
     d->matcher.debugPressedKeys() = QVector(Qt::Key_Space, Qt::Key_Control)

The condition remains while the Space key is held down.

While the Space key is held down, it is ignored and the selected tool is used.
If Ctrl is pressed, the magnifying glass icon is shown but is replaced by the selected tool icon when the stylus is used to draw and the selected tool is used.
If the Shift key is pressed then the line tool cursor is shown and is activated as seen on the canvas drawing and the Toolbox docker icon.

If the Space key is then released, operation goes back to normal until the next Ctrl/Shift mashing with Space held down.
Comment 3 chris 2021-08-20 05:11:52 UTC
This bug is still present in Krita 5 Beta 1. Updating.
Comment 4 Kjartan Tysdal 2021-08-20 09:27:30 UTC
I can confirm that I have observed this multiple times as well in both Krita 4.4.7 and Krita 5 Beta 1. It affects zooming (Space+Ctrl+LMB) and rotate canvas (Space+Shift+LMB).

Windows 10 
Huion Kamvas 22 plus
Comment 5 Kjartan Tysdal 2021-08-20 09:38:29 UTC
*** Bug 432446 has been marked as a duplicate of this bug. ***
Comment 6 Halla Rempt 2021-08-23 11:04:38 UTC
Ah, please don't update the version -- the version field should be for the version the bug was originally reported for.
Comment 7 Ahab Greybeard 2021-09-17 16:44:52 UTC
*** Bug 442547 has been marked as a duplicate of this bug. ***
Comment 8 chris 2021-12-07 09:21:43 UTC
this bug is still present in krita 5.0 beta 5.
Comment 9 Protoniv 2021-12-23 11:01:07 UTC
Tested in 5.0 stable (download from KDE server) on Win10 20H2
I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me.
Comment 10 Protoniv 2021-12-24 03:18:43 UTC
(In reply to Protoniv from comment #9)
> I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me.
After some more test, the Windows Ink is actually from my tablet driver "Use Digital Ink" (XP Pen), if "Use Digital Ink" in tablet driver is off then Windows Ink/WinTab setting in Krita won't occur the bug, at least for me.
Comment 11 chris 2021-12-24 10:35:07 UTC
(In reply to Protoniv from comment #10)
> (In reply to Protoniv from comment #9)
> > I found this bug only happened when I enable Windows Ink, using mouse or WinTab the bug will not occurr to me.
> After some more test, the Windows Ink is actually from my tablet driver "Use
> Digital Ink" (XP Pen), if "Use Digital Ink" in tablet driver is off then
> Windows Ink/WinTab setting in Krita won't occur the bug, at least for me.

Still occurs even with windows ink turned off in the driver for me. Huion Kamvas 13
Comment 12 Alejandro 2021-12-24 15:45:25 UTC
A message to the developers: This bug occurs since the 4.3 version. Maybe you can check the 4.2.9 version (which I'm currently using as it doesn't have the bug) and compare it with the 4.3 to see the code differences and spot what causes the bug. I'm on Windows 10 with a Huion INSPIROY H1161.
Comment 13 Alvin Wong 2022-01-08 08:45:05 UTC
Very reproducible on my Surface Pro 2017. Some quick notes after experimenting:

- Press down Spacebar, press stylus to pan, release stylus, press down Shift, press stylus to rotate, release stylus, THEN release Shift, press stylus to pan works normally
- Press down Spacebar, press stylus to pan, release stylus, press down Shift, press stylus to rotate, release Shift, THEN release stylus, press stylus and it starts painting instead
Comment 14 Zack Keller 2022-01-08 10:21:09 UTC
Still present in 5.0.2.

Modifier keys just spaz out when I pan, rotate and zoom quickly.
Can reproduce it on my main rig (Win10 / Huion WH1409 v2) and my Surface Book 2 (Win10 / Wacom Bamboo Ink).
Comment 15 Dmitry Kazakov 2022-01-08 13:15:45 UTC
I can reproduce the issue following the instructions from KA thread [0]. Steps to reproduce:

1) Hold Space key
2) Start quickly pressing and releasing Ctrl key very quickly
3) Start quick brush strokes with the stylus. It should alternate between zoom and pan actions

Eventually, Krita gives up and forgets that Space key has been pressed.

[0] - https://krita-artists.org/t/krita-is-dropping-keyboard-inputs-or-its-something-else/26585/2
Comment 16 Dmitry Kazakov 2022-01-08 14:20:13 UTC
Git commit 58392a1f9ae446da3f48c632f2bfe68d10a60ee4 by Dmitry Kazakov.
Committed on 08/01/2022 at 14:20.
Pushed by dkazakov into branch 'master'.

Fix Krita forgetting about pressed keys when tapping Ctrl too quickly

Under some circumstances, KeyPress/KeyRelease event comes **after**
a tablet move event with already updated state. It is not very clear
how that happens, but it is surely not impossible. Qt fills modifiers
event property by reading some global storage, so it is possible that
this state is not entirely in sync with the events queue.

The patch does two fixes:

1) KisShortcutMatcher::recoveryModifiersWithoutFocus() used
RecursionNotifier incorrectly, causing keyReleased() and keyPressed()
to reset the state.

2) KisShortcutMatcher::keyReleased() now doesn't reset the state when
discovering inconsistent key release. This change is a bit scary,
because it may lead to longer recovery time when Krita faces a real
trouble with events. But in general it looks "correct".

M  +5    -4    libs/ui/input/kis_shortcut_matcher.cpp

https://invent.kde.org/graphics/krita/commit/58392a1f9ae446da3f48c632f2bfe68d10a60ee4
Comment 17 Dmitry Kazakov 2022-01-08 14:21:29 UTC
Git commit d2b028c9fc8dbe427d944f26b34b833607614e4d by Dmitry Kazakov.
Committed on 08/01/2022 at 14:21.
Pushed by dkazakov into branch 'krita/5.0'.

Fix Krita forgetting about pressed keys when tapping Ctrl too quickly

Under some circumstances, KeyPress/KeyRelease event comes **after**
a tablet move event with already updated state. It is not very clear
how that happens, but it is surely not impossible. Qt fills modifiers
event property by reading some global storage, so it is possible that
this state is not entirely in sync with the events queue.

The patch does two fixes:

1) KisShortcutMatcher::recoveryModifiersWithoutFocus() used
RecursionNotifier incorrectly, causing keyReleased() and keyPressed()
to reset the state.

2) KisShortcutMatcher::keyReleased() now doesn't reset the state when
discovering inconsistent key release. This change is a bit scary,
because it may lead to longer recovery time when Krita faces a real
trouble with events. But in general it looks "correct".
(cherry picked from commit 58392a1f9ae446da3f48c632f2bfe68d10a60ee4)

M  +5    -4    libs/ui/input/kis_shortcut_matcher.cpp

https://invent.kde.org/graphics/krita/commit/d2b028c9fc8dbe427d944f26b34b833607614e4d
Comment 18 Halla Rempt 2022-06-28 11:28:05 UTC
*** Bug 440352 has been marked as a duplicate of this bug. ***