Any-event SGR mouse reports are wrong

[j4james]

Windows Terminal version

1.23.10353.0

Windows build number

10.0.19045.5371

Other Software

No response

Steps to reproduce

1. Open a WSL shell in Windows Terminal
2. Execute printf "\e[?1006;1003h"; read; printf "\e[?1003l"
3. Move the mouse over the terminal window
4. Take note of the final character of the reported mouse events.

Expected Behavior

Those mouse reports should end with an uppercase M.

Actual Behavior

The mouse reports end with a lowercase m.

The spec is a bit confusing, because it says the final character is "M for button press and m for button release", and in this case the button isn't pressed, so you'd think a lowercase m might be more appropriate, but that's not how Xterm implements it (nor any other terminal I've tested). I think the rule is that it only ends with a lowercase m if it's actually a mouse release event.

See also zellij-org/zellij#4065 (comment)

[o-sdn-o]

Does the state of the final character M/m have any meaning in CSI < B ; Px ; Py m when the 'mouse moving' bit inside B is on? I don't think so. Even the bits of the pressed buttons don't matter when moving, since mouse drag with two buttons pressed (e.g. left+right) can't be encoded with this protocol.

[o-sdn-o]

On other hand, Hyrum's law

"With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody."

[DHowett]

I'm happy to ignore Hyrum here. :)

[j4james]

Does the state of the final character M/m have any meaning in CSI < B ; Px ; Py m when the 'mouse moving' bit inside B is on?

@o-sdn-o I think perhaps you're looking at it backwards. It's more like the final character M indicates a button press or move event, while the final character m indicates a button release event. And it's the 'mouse moving' bit that has no meaning in a button release event. But the documentation is not exactly crystal clear.

all observable behaviors of your system will be depended on by somebody

Yeah. In this case it was the termwiz library which was depending on mouse move events being reported with M, and that caused Zellij to break in Windows Terminal (the issue I linked above). That library has now been patched to work around the WT bug (wezterm/wezterm@eb9f860), but I'm willing to bet there'll be other apps or libraries that are similarly affected.