starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-09 02:26:45 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Incorrect escape sequence for mouse up #435

New Issue
Closed
opened 2026-01-30 21:52:21 +00:00 by claunia · 4 comments
claunia commented 2026-01-30 21:52:21 +00:00
Owner
Copy Link

Originally created by @MitchBradley on GitHub (Oct 30, 2018).

Originally assigned to: @zadjii-msft on GitHub.

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

Originally created by @MitchBradley on GitHub (Oct 30, 2018). Originally assigned to: @zadjii-msft on GitHub. 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
claunia added the Product-ConhostResolution-Fix-AvailableWork-Item labels 2026-01-30 21:52:21 +00:00
claunia commented 2026-01-30 21:52:22 +00:00
Author
Owner
Copy Link

@oising commented on GitHub (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.

@oising commented on GitHub (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.
claunia commented 2026-01-30 21:52:22 +00:00
Author
Owner
Copy Link

@MitchBradley commented on GitHub (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.

@MitchBradley commented on GitHub (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.
claunia commented 2026-01-30 21:52:23 +00:00
Author
Owner
Copy Link

@zadjii-msft commented on GitHub (Dec 6, 2018):

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

@zadjii-msft commented on GitHub (Dec 6, 2018): Got a fix for this in PR now. Should be out to Insiders in ~4 weeks.
claunia commented 2026-01-30 21:52:23 +00:00
Author
Owner
Copy Link

@ghost1372 commented on GitHub (Jan 16, 2019):

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

@ghost1372 commented on GitHub (Jan 16, 2019): now fixed https://blogs.windows.com/windowsexperience/2019/01/16/announcing-windows-10-insider-preview-build-18317/#jLDqFi3xDew7UasX.97
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
⛺ Reserved
A11yCO
A11yMAS
A11ySev1
A11ySev2
A11ySev3
A11yTTValidated
A11yUsable
A11yVoiceAccess
A11yWCAG
Area-Accessibility
Area-AtlasEngine
Area-AzureShell
Area-Build
Area-Build
Area-Chat
Area-CmdPal
Area-CodeHealth
Area-Commandline
Area-CookedRead
Area-DefApp
Area-Extensibility
Area-Fonts
Area-GroupPolicy
Area-i18n
Area-Input
Area-Interaction
Area-Interop
Area-Localization
Area-Output
Area-Performance
Area-Portable
Area-Quality
Area-Remoting
Area-Rendering
Area-Schema
Area-Server
Area-Settings
Area-SettingsUI
Area-ShellExtension
Area-ShellExtension
Area-ShellExtension
Area-Suggestions
Area-Suggestions
Area-TerminalConnection
Area-TerminalControl
Area-Theming
Area-UserInterface
Area-VT
Area-Windowing
Area-WPFControl
AutoMerge
Blocking-Ingestion
Culprit-Centennial
Culprit-WinUI
Disability-All
Disability-Blind
Disability-LowVision
Disability-Mobility
External-Blocked-WinUI3
Fixed
Gathering-Data
good first issue
HCL-E+D
HCL-WindowsTerminal
Help Wanted
Impact-Compatibility
Impact-Compliance
Impact-Correctness
Impact-Visual
In-PR
InclusionBacklog
InclusionBacklog-Windows TerminalWin32
InclusionCommitted-202206
Issue-Bug
Issue-Docs
Issue-Feature
Issue-Feature
Issue-Question
Issue-Samples
Issue-Scenario
Issue-Task
Needs-Attention
Needs-Author-Feedback
Needs-Bisect
Needs-Discussion
Needs-Repro
Needs-Tag-Fix
Needs-Tag-Fix
Needs-Triage
No-Recent-Activity
Priority-0
Priority-1
Priority-2
Priority-3
Product-Cmd.exe
Product-Colortool
Product-Colortool
Product-Colortool
Product-Conhost
Product-Conpty
Product-Meta
Product-Powershell
Product-Terminal
Product-WSL
pull-request
Mirrored from GitHub Pull Request
 Resolution-Answered
Resolution-By-Design
Resolution-Duplicate
Resolution-External
Resolution-Fix-Available
Resolution-Fix-Committed
Resolution-No-Repro
Resolution-Won't-Fix
Severity-Blocking
Severity-Crash
Severity-DataLoss
spam
this-will-be-a-breaking-change
Tracking-External
WindowsTerminal_Win32
Work-Item
zAskModeBug
zInbox-Bug
No Label Product-Conhost Resolution-Fix-Available Work-Item
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#435
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?