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

Incorrect DECRQM for Win32InputMode #22108

New Issue
Open
opened 2026-01-31 08:03:41 +00:00 by claunia · 3 comments
claunia commented 2026-01-31 08:03:41 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Aug 18, 2024).

Windows Terminal version

Commit 9b21b78fee

Windows build number

10.0.19045.4780

Other Software

No response

Steps to reproduce

  1. Checkout and build a recent commit of Windows Terminal (I'm assuming it needs to be 450eec48de or later).
  2. Open a tab with a WSL bash shell.
  3. Toggle Win32 input mode with printf "\e[?9001h"; sleep 1; printf "\e[?9001l"; read
  4. You'll likely see the keyup event for the Enter key that you just pressed.
  5. Wait a second and press Enter again to return to the prompt.
  6. Execute showkey -a
  7. Try pressing Esc or Alt+[.

Expected Behavior

You should see the VT codes for those keys like this:

^[       27 0033 0x1b
^[[      27 0033 0x1b
         91 0133 0x5b

Actual Behavior

Neither of those keys are picked up. And I think the problem is the heuristic we're using here:

9b21b78fee/src/terminal/parser/stateMachine.cpp (L2055-L2056)

That works fine if win32 input mode is always on, or always off, but when it's toggled the _encounteredWin32InputModeSequence flag is never reset, so that branch is always skipped.

I don't think this was an issue prior to the new VT passthrough because we never forwarded win32 input mode changes to conpty, so it should have been permanently enabled (assuming it was supported at all).

Originally created by @j4james on GitHub (Aug 18, 2024). ### Windows Terminal version Commit 9b21b78feea9ff0a0b9ff2c8fa4b4aa5602d3889 ### Windows build number 10.0.19045.4780 ### Other Software _No response_ ### Steps to reproduce 1. Checkout and build a recent commit of Windows Terminal (I'm assuming it needs to be 450eec48de252a3a8d270bade847755ecbeb5a75 or later). 2. Open a tab with a WSL bash shell. 3. Toggle Win32 input mode with `printf "\e[?9001h"; sleep 1; printf "\e[?9001l"; read` 4. You'll likely see the keyup event for the <kbd>Enter</kbd> key that you just pressed. 5. Wait a second and press <kbd>Enter</kbd> again to return to the prompt. 6. Execute `showkey -a` 7. Try pressing <kbd>Esc</kbd> or <kbd>Alt</kbd>+<kbd>[</kbd>. ### Expected Behavior You should see the VT codes for those keys like this: ``` ^[ 27 0033 0x1b ^[[ 27 0033 0x1b 91 0133 0x5b ``` ### Actual Behavior Neither of those keys are picked up. And I think the problem is the heuristic we're using here: https://github.com/microsoft/terminal/blob/9b21b78feea9ff0a0b9ff2c8fa4b4aa5602d3889/src/terminal/parser/stateMachine.cpp#L2055-L2056 That works fine if win32 input mode is always on, or always off, but when it's toggled the `_encounteredWin32InputModeSequence` flag is never reset, so that branch is always skipped. I don't think this was an issue prior to the new VT passthrough because we never forwarded win32 input mode changes to conpty, so it should have been permanently enabled (assuming it was supported at all).
claunia added the Issue-BugArea-InputArea-VTProduct-Conpty labels 2026-01-31 08:03:41 +00:00
claunia commented 2026-01-31 08:03:42 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Aug 18, 2024):

The more I think about this, the more I believe there may be a bigger problem with win32 input mode in general.

Prior to the new passthrough, the terminal would have appeared as if win32 input mode was not enabled. DECRQM would report the mode as reset, and ENABLE_VIRTUAL_TERMINAL_INPUT would generate standard VT input sequences. It was just the internal communication between conhost and Windows Terminal that had win32 input mode enabled.

With the new system, DECRQM now reports the mode as set by default, but doesn't actually behave that way. If you request ENABLE_VIRTUAL_TERMINAL_INPUT you're still going to receive standard VT input sequences, unless you explicitly enable win32 input mode yourself.

And apps that do enable win32 input mode will typically disable it when they exit. That's probably OK for WSL apps (assuming we fix the bug reported above), but if you're in a win32 shell, that's going to leave the system in a state where it doesn't report all the key combinations, which is not ideal.

But it's even worse if the app tries to restore the mode to what it detected at startup, because in that case it'll exit with win32 input mode enabled, which will make a WSL shell unusable. And while it may be a good thing for win32 console apps that read INPUT_RECORD events, it's going to break any apps that are using ENABLE_VIRTUAL_TERMINAL_INPUT, and which are expecting standard VT input sequences.

@j4james commented on GitHub (Aug 18, 2024): The more I think about this, the more I believe there may be a bigger problem with win32 input mode in general. Prior to the new passthrough, the terminal would have appeared as if win32 input mode was not enabled. `DECRQM` would report the mode as reset, and `ENABLE_VIRTUAL_TERMINAL_INPUT` would generate standard VT input sequences. It was just the internal communication between conhost and Windows Terminal that had win32 input mode enabled. With the new system, `DECRQM` now reports the mode as set by default, but doesn't actually behave that way. If you request `ENABLE_VIRTUAL_TERMINAL_INPUT` you're still going to receive standard VT input sequences, unless you explicitly enable win32 input mode yourself. And apps that do enable win32 input mode will typically disable it when they exit. That's probably OK for WSL apps (assuming we fix the bug reported above), but if you're in a win32 shell, that's going to leave the system in a state where it doesn't report all the key combinations, which is not ideal. But it's even worse if the app tries to restore the mode to what it detected at startup, because in that case it'll exit with win32 input mode _enabled_, which will make a WSL shell unusable. And while it may be a good thing for win32 console apps that read `INPUT_RECORD` events, it's going to break any apps that are using `ENABLE_VIRTUAL_TERMINAL_INPUT`, and which are expecting standard VT input sequences.
claunia commented 2026-01-31 08:03:42 +00:00
Author
Owner
Copy Link

@lhecker commented on GitHub (Aug 21, 2024):

I believe what's missing was a call to InjectSequence in the W32IM_Win32InputMode handler. The large comment next to it even calls out how we shouldn't bubble up the sequence to the parent terminal.

@lhecker commented on GitHub (Aug 21, 2024): I believe what's missing was a call to `InjectSequence` in the `W32IM_Win32InputMode` handler. The large comment next to it even calls out how we shouldn't bubble up the sequence to the parent terminal.
claunia commented 2026-01-31 08:03:42 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Aug 21, 2024):

(#17757 may not help DECRQM)

@DHowett commented on GitHub (Aug 21, 2024): (#17757 may not help `DECRQM`)
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 Area-Input Area-VT Issue-Bug Product-Conpty
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#22108
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?