Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect escape sequence for mouse up #296

MitchBradley opened this Issue Oct 30, 2018 · 4 comments


None yet
6 participants
Copy link

MitchBradley commented Oct 30, 2018

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:


This comment has been minimized.

Copy link

oising commented Oct 30, 2018

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.

@zadjii-msft zadjii-msft self-assigned this Oct 30, 2018

@zadjii-msft zadjii-msft added this to the 19H1 milestone Oct 30, 2018


This comment has been minimized.

Copy link

MitchBradley commented Oct 30, 2018

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.


This comment has been minimized.

Copy link

zadjii-msft commented Dec 6, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.