This was a somewhat insidious bug I discovered while building darkly.art. Basically, after touching the window with the pen, mouse input would stop working for all of chrome, until you moved the cursor off of chrome and back in again.
Diagnosing it took more than a week and Claude Opus 5 proved useful for troubleshooting and fixing. I ran a full compile and tested with and without the fix.
I also added three tests. Two are regression tests that fail without the fix; the third is a sanity check that passes either way.
Thanks for your time on this
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +1 |
+tluk for secondary approval (fangzhoug is OOO)
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
ozone/wayland: Restore pointer focus on tablet tool proximity out
WaylandTabletTool called into the pointer delegate with a null window on
proximity out, clearing WaylandWindowManager's pointer focused window.
The mouse never left the surface, so the compositor sends only
wl_pointer.motion and no new wl_pointer.enter -- and wl_pointer.enter is
the only thing that restores pointer focus. OnPointerMotionEvent,
OnPointerFrameEvent and the pointer button path then all early-return on
the null target, so mouse input stopped entirely, with the cursor frozen
on its last shape, until the cursor physically left and re-entered the
window or the tool re-entered proximity.
Verified with WAYLAND_DEBUG under Sway: after zwp_tablet_tool_v2
.proximity_out the compositor delivered 470 wl_pointer.motion events that
were all ignored, and wl_pointer.set_cursor was never called again. No
mid-session wl_pointer.leave was sent.
Stylus tab dragging resolves its drag origin through the pointer focused
window, so the tool must hold it while in proximity. Track the window
wl_pointer last entered and hand focus back on proximity out instead of
clearing it.
Also gives OnTabletToolProximityOut a PointerDetails parameter, which it
alone among the four tablet delegate methods lacked, so its exit event
carries the tool's pointer type instead of defaulting to a mouse.
R=thomasa...@chromium.org
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |