Skip to content

fix(win32): forward bare mouse motion as SGR button 35 for hover#77

Open
KoalaHao wants to merge 1 commit into
Norbert515:mainfrom
marsup-space:fix/windows-mouse-hover
Open

fix(win32): forward bare mouse motion as SGR button 35 for hover#77
KoalaHao wants to merge 1 commit into
Norbert515:mainfrom
marsup-space:fix/windows-mouse-hover

Conversation

@KoalaHao
Copy link
Copy Markdown

@KoalaHao KoalaHao commented Jun 5, 2026

Windows reports a MOUSE_EVENT for every pixel of movement, including hover. The previous code returned [] for bare motion (no button held), so MouseRegion and onHover callbacks never fired on Windows.

Now emits SGR button code 35 (motion flag 0x20 + base button 3), matching the Linux path's SGR mode 1003 encoding. MouseParser already classifies button 35 as a hover event (isMotion: true, pressed: false), so the framework receives the same MouseEvent shape it gets on Linux and the two backends stay in lock-step.

No effect on click/drag handling: those continue to use their existing button codes (0/1/2 for press, 32+offset for drag).

Windows reports a MOUSE_EVENT for every pixel of movement, including
hover. The previous code returned [] for bare motion (no button
held), so MouseRegion and onHover callbacks never fired on Windows.

Now emits SGR button code 35 (motion flag 0x20 + base button 3),
matching the Linux path's SGR mode 1003 encoding. MouseParser already
classifies button 35 as a hover event (isMotion: true, pressed:
false), so the framework receives the same MouseEvent shape it gets
on Linux and the two backends stay in lock-step.

No effect on click/drag handling: those continue to use their
existing button codes (0/1/2 for press, 32+offset for drag).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant