https://bugs.kde.org/show_bug.cgi?id=523559
Bug ID: 523559
Summary: Windows: canvas still receives MMB/wheel events after
refocus, but pan/zoom no longer activates
Classification: Applications
Product: krita
Version First 5.3.2.1
Reported In:
Platform: Microsoft Windows
OS: Microsoft Windows
Status: REPORTED
Severity: normal
Priority: NOR
Component: OpenGL Canvas
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 194642
--> https://bugs.kde.org/attachment.cgi?id=194642&action=edit
After returning focus to Krita, canvas navigation can stop working even though
drawing still works.
Version: 5.3.2.1
OS: Windows 10.0.26100
Component: Canvas input / shortcuts / Windows focus handling
Title: Windows: canvas still receives MMB/wheel events after refocus, but
pan/zoom no longer activates
SUMMARY
After returning focus to Krita, canvas navigation can stop working even though
drawing still works.
- LMB drawing still works
- MMB pan fails
- mouse-wheel zoom fails
- closing/reopening the document does not fix it
- switching tools does not fix it
- changing canvas input bindings does not fix it
- in the cleanest cases: no active modal, no popup, no stuck native MMB state
- logging shows MMB and wheel events still reach KisOpenGLCanvas2, but Krita
does not pan/zoom
This appears to be an internal Krita canvas navigation/input-state desync,
likely related to Windows focus changes / alt-tab.
EXPECTED RESULT
When Krita regains focus, canvas navigation should continue working:
- middle mouse button should pan
- mouse wheel should zoom
- alternative canvas navigation bindings should continue to work
ACTUAL RESULT
After refocusing Krita:
- LMB still draws
- MMB does not pan
- mouse wheel does not zoom
- Krita otherwise remains responsive and the document can still be edited
- the canvas widget continues to receive the events, but navigation does not
trigger
REPRODUCTION PATTERN
Intermittent. Most common pattern:
1. Work in Krita normally for some time
2. Alt-tab / leave Krita for other apps
3. Return to Krita
4. Click the canvas
5. Try MMB pan and mouse-wheel zoom
6. Result: LMB still draws; MMB pan and wheel zoom do not work
Can also happen after long sessions; sometimes appears immediately after
returning focus.
THINGS ALREADY RULED OUT
- closing/reopening the document
- switching tools (brush/select etc.)
- restarting Krita multiple times
- canvas input limited to MMB pan and Space+LMB pan
- disabling some plugins
- closing an AutoHotkey script with Krita-specific hotkeys
- Task Manager showed only one Krita window
Other observations:
- other apps still detect middle mouse correctly
- not explained by the canvas input bindings themselves
- not consistently tied to a visible modal dialog
- cleanest logged case: no active modal, no popup, no stuck native key/button
state
RELATED INPUT CONFIGURATION
Pan Canvas:
- Space + Left Button -> Pan Mode
- Middle Button -> Pan Mode
- Mouse Wheel: Trackpad Pan -> Pan Mode
- One Finger Drag -> Pan Mode
Zoom Canvas:
- Ctrl + Left Button -> Relative Zoom Mode
- Mouse Wheel Up -> Zoom Out From Cursor
- Mouse Wheel Down -> Zoom In To Cursor
These bindings have been used for years without issues until recently.
IMPORTANT LOGGED EVIDENCE
A local diagnostic plugin logged Qt/Krita input state during failures.
Clean no-modal stuck case (2026-07-27 01:07:23 manual dump):
- activeModal: (none)
- activePopup: (none)
- focusWidget: KisOpenGLCanvas2
- activeWindow: KisMainWindow
- nativeKeyState: stuck=(none)
- canvasWidget: KisOpenGLCanvas2
- RISKY: no
While still stuck, the log then captured:
- 2026-07-27 01:07:29 POST-RESUME MMB | under=KisOpenGLCanvas2 ...
canvasUnder=True
- 2026-07-27 01:07:32 POST-RESUME WHEEL | under=KisOpenGLCanvas2 ...
canvasUnder=True
Meaning: focus was already on the canvas; no modal/popup/grabber; native state
clear; MMB/wheel landed on KisOpenGLCanvas2; but Krita still did not pan or
zoom.
Earlier transient native MMB case (2026-07-27 00:19:26):
- briefly recorded nativeKeyState: stuck=MMB
- later clean reproductions showed stuck=(none) while the issue remained
So a transient native MMB desync may happen sometimes, but does not explain all
stuck cases.
Separate modal cases (not the core bug being reported):
- KisDlgPreferences title='Configure Krita'
- QMessageBox title='Krita'
Those are separate from the clean no-modal reproductions above.
WHY THIS SEEMS LIKE A KRITA BUG
In the clean failure state:
- Krita is focused
- canvas widget is focused
- no modal or popup is active
- native key/button state is clear
- MMB and wheel events still target the canvas widget
but canvas navigation still does not happen.
That suggests Krita's internal canvas navigation/input matcher gets into a bad
state after focus changes, rather than events being blocked externally. Related
to known Windows focus/input desync issues, but this case has logging showing
events still arrive at the canvas.
ADDITIONAL NOTES
- LMB drawing remains functional; navigation specifically fails
- seems connected to focus changes / returning to Krita after other windows
- can persist across closing/reopening documents
- disrupts workflow because navigation becomes unavailable while the document
remains editable
SUGGESTED ATTACHMENTS
1. relevant excerpt from input_watch.log
2. screenshot of current canvas input bindings
3. note that Task Manager showed only one Krita window
--
You are receiving this mail because:
You are watching all bug changes.
