SUMMARY *** Under Windows, Krita loses modifier and mouse click canvas input due to certain apps aggressively stealing focus. User would experience symptoms like "broken shortcuts" and "unable to pick color by pressing down Ctrl", "unable to call popup palette", "unable to move canvas view by middle button". But in fact, this has nothing to do with shortcuts. For example, single key shortcuts like B, E, etc are not affected. Non canvas input shortcuts with modifier (like Ctrl+S for saving document) are not affected. I found out that this problem has something to do with certain apps aggressively stealing focus -- by them either showing persistent popups, or showing a high priority dialogue that listens to user input in real time, all time. If Krita's focus got stolen, I must first close those popups/dialogues, then restart Krita to get the modifiers and mouse clicks working again. *** STEPS TO REPRODUCE Here I will use Sogou Pinyin (搜狗拼音输入法) ( https://shurufa.sogou.com/) as example. Sogou Pinyin is a popular Chinese input app. Almost every PC in China have this app as the default input method -- meaning it will always have a toolbar on screen. Sogou Pinyin steals focus at EITHER of the following situations: 1. Switching from other Input method to Sogou Pinyin; 2. Sogou Pinyin showing a persistent advertisement popup above its toolbar, you must click the X button to close it; 3. Sogou Pinyin's Voice Input dialogue in open (press the "microphone" button on its toolbar). OBSERVED RESULT If ANY of the situations above happened, Krita immediately loses its modifier key input and middle/right button input. Restarting Krita alone won't solve the issue. Sogou Pinyin's AD Popups/Voice Input dialogues must be closed before restarting Krita to solve this issue. SOFTWARE/OS VERSIONS Windows: Windows 11 23H2 ADDITIONAL INFORMATION There is a KA forum discussion thread about this issue: https://krita-artists.org/t/if-i-click-away-from-krita-my-shortcuts-break-5-1-1/51977/10 Although I think their understanding was inaccurate. I was unable to reproduce any of their claims about WeChat PC client causing issues. This issue is a very serious threat to our userbase in China, given how popular Sogou Pinyin is in this region. I began to hear about this around 2022 when Sogou Pinyin was rewritten. Many users were forced away from Krita because of this issue making them unable to use Krita, and no one seemed to know what caused it. I have reported this issue to Sogou Pinyin. But I doubt they will do anything. It is worth mention that every other art apps aren't being affected like Krita. Maybe they have implemented specific workarounds for this issue. Maybe if Krita can steal focus more aggressively, we can solve this problem.
Here I will repeat the important points in Chinese, so people can find this bug report easier. Krita 在 Windows 下面会因为某些其他程序使用激进的手段抢夺窗口焦点而导致 Krita 的画布输入失去修饰键 (Ctrl/Shift/Alt) 和鼠标中键/右键。没有经验的用户体验到的表象是“快捷键失效”、“Ctrl键按下不能拾色”、“无法打开右键弹出面板”、“无法用中键移动画布”等。然而实际上这和快捷键没有关系——单键的快捷键 (如B/E/R/V 等)，带修饰键的非画布快捷键 (Ctrl+S 等) 的工作依然是正常的。 以搜狗拼音输入法为例，我的测试发现在以下的任意情况下它会积极地抢夺 Krita 的焦点： 1. 从其他输入法切换到搜狗拼音 2. 显示推广气泡 (在搜狗输入法工具栏上方偶尔出现的单行文字提示，例如推广语音输入、AI写作等功能) 3. 搜狗拼音的语音输入 (麦克风按钮) 点击后打开了语音输入框在实时监听用户输入时 必须将这些气泡、弹窗、对话框全部关闭 (不需要关闭搜狗输入法本身)，然后重启 Krita，这样 Krita 的画布快捷键输入才会恢复正常。 我已经将这个问题通过搜狗输入法内建的反馈功能提交给他们了，虽然他们大概率不会做任何事情。 我记得这个问题并不是一直存在的，好象是从 2022 年左右搜狗拼音被重写时才开始陆续发现有人报告这个问题，而且当时貌似很多其他绘画软件也遇到不少奇怪的丢输入的情况。不知道是不是一回事。 虽然有人说微信可能也会导致问题，但是我测试的时候同时打开了QQ、微信、钉钉、B站、网易云音乐、百度网盘、360浏览器等这些常见软件，全部默认设置直接用，它们各自都有推送消息弹窗等，但我并没有遇到任何问题——只有搜狗拼音才会发生问题。
After more investigation, I discovered some important clues that point to Krita/Qt. 1) Krita 4.2.9 was unaffected by this bug. 2) The problem started to happen since 4.3.0beta1. 3) I tested this personally, using binaries from KDE Attic: https://download.kde.org/Attic/krita/ Krita 4.3 Release Notes: https://krita.org/en/release-notes/krita-4-3-release-notes/ Qt version difference: Krita 4.2.9 uses Qt 5.12.7. Krita 4.3.0beta1 uses Qt 5.12.8 Qt 5.12.8 Release Notes: https://www.qt.io/blog/qt-5.12.8-released Fixed bugs in Qt 5.12.8: https://bugreports.qt.io/browse/QTBUG-79192?filter=21875
To add to my discovery in Comment 3: In my initial report Description and Comment 1 I said I was only able to reproduce the issue with Sogou Pinyin Input Method. This turned out to be inaccurate. In reality, almost every popular Instant Messaging app in China was affected. This includes: 1) QQ (the old 9.7.x branch) 2) Dingtalk 3) Weixin These apps require Chinese ID to register an account, so it's not practical for the Krita team to test them. I will include what triggered the issue in these apps below.
Tencent QQ (Old branch): https://im.qq.com/ https://im.qq.com/pcqq/index.shtml https://dldir1.qq.com/qqfile/qq/PCQQ9.7.22/QQ9.7.22.240318_01.exe Only the old 9.7.x branch was affected. The recently rewritten 9.9.x branch is unaffected. The old branch was written in C. The new branch is Electron based. The Startup and Login sequence of this old QQ will break Krita's canvas shortcuts. Nothing else.
Dingtalk (钉钉): https://www.dingtalk.com/ https://page.dingtalk.com/wow/z/dingtalk/simple/ddhomedownload#/ This app seems to be Qt based. It has Qt 5.15.11 libraries in its installation directory. The Starting up, Login Sequence, New Message Notifications seemed to break Krita's canvas shortcuts. After turning off all of Dingtalk's global hotkeys, I was unable to reproduce this issue anymore.
Weixin PC Client (微信 PC 客户端): https://weixin.qq.com/ https://pc.weixin.qq.com/ Weixin PC Client appears to be Electron based. The following behaviors break Krita's canvas shortcuts: 1) The Login of Weixin PC Client bringing up its main window above other apps. 2) The chat dialogue has an "Emotion" button. Clicking this icon to open the Emotion GIF list. 3) Clicking "Mini Programs (小程序)" icon on its Left sidebar opens a special dialogue window. 4) Clicking "Channels (视频号)" icon on its Left sidebar opens a special dialogue window. There is no known workaround for Weixin except avoiding the actions above.
On another note, I've also discovered a workaround inside Krita. Whenever Krita lost its Canvas Shortcuts: 1) Click "Choose Workspace" button on the right of Krita's toolbar. 2) Change to another Workspace and back. 3) Krita's Canvas shortcuts is restored temporarily. However, if the upper mentioned 3rd party apps trigger the issue again, Krita will lose its Canvas Shortcuts again.
Additionally, when Krita's Canvas Shortcuts are broken: Mouse wheel Up/Down to Zoom is also broken. Possibly because it's also a Canvas Shortcut?
I also traced back this issue to a Krita-Artist forum post: https://krita-artists.org/t/4-3-beta-1-certain-keyboard-shortcuts-not-working/7027/9 This user is not Chinese, so this issue is not China specific. And the post is 4.3.0beta1 related.
To sum the important new findings up: 1) Something happened between Krita 4.2.9 and 4.3.0beta1 caused this issue. 2) Or maybe something happened between Qt 5.12.7 and 5.12.8 caused it. 3) This is not China specific. 4) Changing Krita's workspace restores Canvas Shortcuts temporarily. Therefore, I think this is indeed a Krita problem. Maybe since 4.3.0beta1, Krita 's canvas focus restore mechanism has been broken.
Better to have a minimal example(about the Canvas Shortcuts) to reproduce the bug? And the steps.
I can try to record a video with Key stroke visualization, if that's what you mean. I will do it later tonight.
I mean code example if possible, Krita is too huge for a qt dev to recompile when trying a "git bisect".
I don't think I have the knowledge to do that. Maybe a Krita dev knows how. I will first try to investigate this with the Krita devs, and get back to you if what we found was indeed a Qt bug.
Maybe this bug is related to: https://bugs.kde.org/show_bug.cgi?id=462768
Created attachment 168054 [details] Krita tablet event log during the issue This tablet event log ended with a suspicious message: WARNING: modifiers state became inconsistent! Trying to fix that... inputEvent->modifiers() = QFlags<Qt::KeyboardModifier>(NoModifier) d->matcher.debugPressedKeys() = QVector(Qt::Key_Shift, Qt::Key_Control, Qt::Key_T, Qt::Key_F22) It has "modifiers state inconsistant" and the repeatedly reported "F22" key like many other users reported.
Created attachment 168055 [details] Video of Krita's canvas shortcut issue
*** Bug 449000 has been marked as a duplicate of this bug. ***
*** Bug 470354 has been marked as a duplicate of this bug. ***
Someone has written a plugin for this issue: https://github.com/V-YOP/krita-shortcut-fix https://github.com/V-YOP/krita-shortcut-fix/blob/main/README.md If a plugin can do it, there is no reason that Krita cannot do it. I think it would be better for Krita to address this issue internally, because no other drawing app has the same issue. This bug has been turning away Krita's user in China. People in China are much less enthusiastic about Krita mostly because of this bug never got fixed for so many years. People can't just give up WeChat for Krita, because WeChat is an essential link in our daily life and work.
Someone has reportedly located the commit that caused this bug: Commit f49dac3a Fix pan/zoom shortcuts not working after accessing any docker https://invent.kde.org/graphics/krita/-/commit/f49dac3a603d8d40108523be436be1b251966ac5
Based on https://github.com/V-YOP/krita-shortcut-fix/blob/main/shortcut_fix/shortcut_fix.py , it sounds WeChat is using F22 pressed, Krita need to ignore the status on Windows for WeChat. If some Krita dev could help, just create a simple patch and build a binary for you to test. I suggest you contact dev in their "irc" channels.
google "wechat f22 pressed", top results from Krita...
https://invent.kde.org/graphics/krita/-/commit/f49dac3a603d8d40108523be436be1b251966ac5 in KisExtendedModifiersMapper::queryExtendedModifiers(), it should just check the status for those modifiers, not all keys. At least for the code of X11 part, it only checks Shift/Control/Alt/Meta.
Hi, all! Could you please check this build of Krita? Does it fix the F22 issue on your systems? https://disk.yandex.ru/d/jBZHpA5lYSL5Mw (this build is based on Qt6, so it might be broken in other ways, especially in the canvas rendering area, just ignore the unrelated issues)
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2416
Thanks, I put it at BaiduNetDisk, Link: https://pan.baidu.com/s/1eGSrAlgKW7b5LcdeDJq3YA?pwd=v9jy Passcode: v9jy
Thank you, Liang and Dmitry! I will test the package in a minute. I will also relay this message to the local community so they can try it out too. To those who lives in China, use this link if you can't access Yandex: https://share.weiyun.com/K3r92UM1 各位，Dmitry 刚刚针对微信的 F22 问题构建了一个测试用的 Krita 版本，感兴趣的请协助测试。为了方便无法直接访问俄罗斯 Yandex 网盘的用户，我已经将它上传到了腾讯微云： https://share.weiyun.com/K3r92UM1
OK, I have tested the new Krita package. I think the problem has been fixed. No matter how hard I tried, I was unable to trigger this bug. Thank you guys!
> OK, I have tested the new Krita package. I think the problem has been fixed. No matter how hard I tried, I was unable to trigger this bug. Thank you guys! Okay, it seems like I need to make a proper patch for that. I have completely disabled parsing of F22 key inside Qt ;) Qt just never sends any events for it. Are there any known cases when keys F13 and higher are used in the system? Should I just make an option to "Ignore all F13-F22 keys" in Krita settings? Or should I just ignore F22?
As far as I know, the only case is WeChat's F22 key, which cannot be disabled. However, it is wise to ignore all such keys—who knows if someone might use them? The only potential use I can think of would be mapping a device (like a gamepad) to virtual Fx keys. Still, I don't believe this edge case justifies the risk of disrupting Krita's shortcuts for everyone.
Ignore F22 could fix this ticket. But in general, F13-F24 physical keys are very rare nowadays. See the picture in https://discuss.kde.org/t/remapping-keys-such-as-f13/10275/2 . We could ignore F13-F24 in a separate change, anyway, we could get some feedback after users tried it. Or we could have default option to ignore, but users could turn it on to not ignore somewhere, that's just for safe.
Sorry if I was unclear in Comment 31. I agree with Liang Qi's suggestion to disable all F13-F24 keys. I don't think many users will need them in Krita. Most of us use the standard 102 keyboard, anyway. Keeping any of these keys functional is too risky. WeChat's F22 issue has set Krita back in China for years. We can't allow careless developers to disrupt us again.
A possibly relevant merge request was started @ https://invent.kde.org/graphics/krita/-/merge_requests/2418
Hi, Tyson and others! Could you please test this package? https://invent.kde.org/graphics/krita/-/jobs/3054828/artifacts/raw/krita-x64-5.3.0-prealpha-ec1bd61c.zip It is the "production ready" version of the previous version of the package. The main difference is that the option to ignore F13-F24 keys is disabled by default and you need to enable it manually. 1) Download the package 2) Go to Preferences->General->Miscellaneous 3) Set checkbox "Ignore high function keys (F13-F24)" The feature should enable instantly PS: The build is from this MR: https://invent.kde.org/graphics/krita/-/merge_requests/2418
Hi Dmitry, Yes, the test package worked as intended. Thank you everybody! However, I would strongly, strongly recommend having this option enabled by default. Reason: Nobody is using a keyboard with F13-F24 keys these days. 99% of Windows PC in China has WeChat installed. If we don't enable this option by default, Krita will continue to break out-of-the-box for almost every Chinese user. This is a very bad first impression, and an unnecessary hindrance for a significant chunk of our user base. In fact, this bug is THE show-stopper for Krita in China. I'm pretty sure we have lost many users, old and new, just because of this bug. I don't think it is wise to expect people to search on the Internet for solutions. People have no idea that WeChat and F22 caused the issue, so they wouldn't know what to search. Even if they can reach this bug report, most of them can't read English. We now have the opportunity to make things work out-of-the-box. I hope we can enable this option by default, so we can finally promote Krita in China again.
Also reported this bug to Chromium: https://issues.chromium.org/issues/427778321
Hi Dmitry, As mentioned in Comment 24, on Linux, Krita doesn't use function keys as modifiers. On macOS, Krita also doesn't use function keys as modifiers. Could you clarify in what situations Windows Krita users use function keys—especially F13 to F24—as modifiers?
> Could you clarify in what situations Windows Krita users use function keys—especially F13 to F24—as modifiers? Well, you can assign F13-F24 keys as modifiers in Krita. The problem is not technically in "users use function keys—especially F13 to F24—as modifiers", but that we have an internal state automata for all the keys supported by Qt, so, theoretically, KisExtendedModifiersMapper should read as much keys as possible on the platform to make the state automata consistent. As an alternative solution, we could just declare a predefined closed list of keys that we allow as modifiers and ignore all the other keys in the state automata. Though I'm not very sure how possible it is, given the amount of possible keyboard layouts, dead keys and stuff like that. That would require a lot of testing at least.
Git commit ac44bfa434fccdb5d91f0300ba204c79327a60d8 by Dmitry Kazakov. Committed on 01/07/2025 at 12:27. Pushed by dkazakov into branch 'master'. Implement option for ignoring of F13-F24 keys on Windows Some apps (e.g. WeeChat) uses emulated F22 key press to bring itself to the toplevel. Since the key is unbalanced, it confuses Krita. So we implemented an option just to ignore all F13+ keys for users who have this problem. Thanks Wendy Gan (@gwdx) for the original suggestion of the fix in https://invent.kde.org/graphics/krita/-/merge_requests/2416. This patch also implements this change, but makes it configurable. M +10 -0 libs/ui/dialogs/kis_dlg_preferences.cc M +43 -33 libs/ui/forms/wdggeneralsettings.ui M +7 -2 libs/ui/input/kis_extended_modifiers_mapper.cpp M +13 -0 libs/ui/input/kis_input_manager.cpp M +1 -0 libs/ui/input/kis_input_manager.h M +18 -0 libs/ui/input/kis_input_manager_p.cpp M +3 -0 libs/ui/input/kis_input_manager_p.h M +10 -0 libs/ui/kis_config.cc M +3 -0 libs/ui/kis_config.h https://invent.kde.org/graphics/krita/-/commit/ac44bfa434fccdb5d91f0300ba204c79327a60d8
Git commit fac44df05e66d70049bad9d09a2bd4e9ff2b427e by Dmitry Kazakov. Committed on 01/07/2025 at 13:42. Pushed by dkazakov into branch 'krita/5.2'. Implement option for ignoring of F13-F24 keys on Windows Some apps (e.g. WeeChat) uses emulated F22 key press to bring itself to the toplevel. Since the key is unbalanced, it confuses Krita. So we implemented an option just to ignore all F13+ keys for users who have this problem. Thanks Wendy Gan (@gwdx) for the original suggestion of the fix in https://invent.kde.org/graphics/krita/-/merge_requests/2416. This patch also implements this change, but makes it configurable. M +10 -0 libs/ui/dialogs/kis_dlg_preferences.cc M +16 -6 libs/ui/forms/wdggeneralsettings.ui M +7 -2 libs/ui/input/kis_extended_modifiers_mapper.cpp M +13 -0 libs/ui/input/kis_input_manager.cpp M +1 -0 libs/ui/input/kis_input_manager.h M +18 -0 libs/ui/input/kis_input_manager_p.cpp M +3 -0 libs/ui/input/kis_input_manager_p.h M +10 -0 libs/ui/kis_config.cc M +3 -0 libs/ui/kis_config.h https://invent.kde.org/graphics/krita/-/commit/fac44df05e66d70049bad9d09a2bd4e9ff2b427e
Thank you, Dmitry! :)
Hi, Tyson! Could you please check this Windows package if it still fixes the issue? https://invent.kde.org/graphics/krita/-/jobs/3080343/artifacts/browse It is the upcoming 5.2.10 release that we issue specifically for this bugfix
Hi Dmitry, yes, the new 5.2.10 package still fixes the issue for me.
H, Tyson! Thank you very much for the help with testing! :)