Incorrect escape sequence for mouse up

[MitchBradley]

Microsoft Windows [Version 10.0.17134.345]

When the new console subsystem is configured to pass mouse events to running applications as escape sequences in SGR mode, the mouse up event is reported as "button 4 up", regardless of which button was pressed. For example, when the left mouse button is pressed/released, the escape sequence should be

ESC [< 0 ; col ; row M
ESC [< 0 ; col ; row m

i.e. left button (0) down (M) then up (m)

Instead, console sends this sequence:

ESC [< 0 ; col ; row M
ESC [< 3 ; col ; row m

i.e. left button (0) down (M), then fourth button (3) up (m).

Regardless of which mouse button is pressed, the up event always says button number 3 instead of the correct button.

One simple repro involves running bash under WSL, with "Quick Edit Mode" turned off in the console properties. Use echo as belo to enable mouse reports in SGR mode, then press/release the left mouse button.

wmb@DESKTOP-6I1SH7T:~$ echo -e "\e[?1000h\e[?1006h"

wmb@DESKTOP-6I1SH7T:~$ 0;31;30M3;31;30m

In the last line above, which shows the printable parts of the mouse report sequence, the character after M is 3, but it should be 0. The 31 and 30 numbers depend on the mouse position; it is the 0; .. 3; (should be 0; .. 0;) that is the problem.

I first noticed this problem using emacs in a docker container with xterm-mouse-mode with mouse-wheel-mode enabled. The symptom there is that a left mouse click is followed by a spurious wheel scroll action. After isolating the problem to "wrong up event", I then reproduced it using many different ways of displaying the mouse escape sequence (all under the new console subsystem).

The following reference describes the expected behavior, which is consistent with the behavior of xterm under Linux:

http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

[oising]

I can confirm this. I was in the middle of trying to figure out the codes and repro, but you beat me to it. I'm on build 1809 and it's been like this since VT codes were first enabled.

[MitchBradley]

Fortunately this is the sort of thing that is probably trivial to fix. Unfortunately, release cycles are release cycles. Meanwhile, a workaround for me, in emacs, is to turn off mouse wheel mode, so that the spurious mouse4-up event is unbound and thus discarded. I can live without mouse wheel scrolling for the nonce.

[zadjii-msft]

Got a fix for this in PR now. Should be out to Insiders in ~4 weeks.

[ghost1372]

now fixed
https://blogs.windows.com/windowsexperience/2019/01/16/announcing-windows-10-insider-preview-build-18317/#jLDqFi3xDew7UasX.97