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

Reset disables the ability to pass through C1 control characters #18425

New Issue
Closed
opened 2026-01-31 06:13:36 +00:00 by claunia · 5 comments
claunia commented 2026-01-31 06:13:36 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (Sep 11, 2022).

Windows Terminal version

1.15.1862.0

Windows build number

10.0.19044.1889

Other Software

No response

Steps to reproduce

  1. Open a WSL bash shell in Windows Terminal.
  2. Execute the following statement: printf "\e 7\u009B?5h"
  3. Note that the screen attributes have reversed.
  4. Execute reset to get the screen back to normal.
  5. Execute printf "\e 7\u009B?5h" again.

Expected Behavior

Both step 2 and step 5 should cause the screen attributes to be reversed.

Actual Behavior

Only the first attempt works. The second attempt appears to output ?5h instead.

What's happening is we've got a DECAC1 sequence (ESC SP 7) which is supposed to enable C1 support, followed by DECSCNM (reverse screen mode), using a C1 control sequence (CSI ? 5 h).

That works the first time, but after the reset, the C1 support is permanently disabled on the conpty client side, so C1 control sequences can no longer be passed through.

Originally created by @j4james on GitHub (Sep 11, 2022). ### Windows Terminal version 1.15.1862.0 ### Windows build number 10.0.19044.1889 ### Other Software _No response_ ### Steps to reproduce 1. Open a WSL bash shell in Windows Terminal. 2. Execute the following statement: `printf "\e 7\u009B?5h"` 3. Note that the screen attributes have reversed. 4. Execute `reset` to get the screen back to normal. 5. Execute `printf "\e 7\u009B?5h"` again. ### Expected Behavior Both step 2 and step 5 should cause the screen attributes to be reversed. ### Actual Behavior Only the first attempt works. The second attempt appears to output `?5h` instead. What's happening is we've got a `DECAC1` sequence (`ESC SP 7`) which is supposed to enable `C1` support, followed by `DECSCNM` (reverse screen mode), using a `C1` control sequence (`CSI ? 5 h`). That works the first time, but after the reset, the `C1` support is permanently disabled on the conpty client side, so `C1` control sequences can no longer be passed through.
claunia added the Needs-TriageResolution-Fix-CommittedIssue-BugNeeds-Tag-Fix labels 2026-01-31 06:13:37 +00:00
claunia commented 2026-01-31 06:13:38 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 11, 2022):

I think this may be another regression from #13024.

When we first added support for DECAC1 in #11690, the assumption was that it would be enabled permanently on the conpty client side, and there was nothing in the terminal code that could turn that off. However, when TerminalDispatch was replaced with AdaptDispatch, it inherited the conhost SoftReset implementation, and that included turning off DECAC1.

I haven't tried this yet, but one simple fix could be to add another parser mode - something like AlwaysAcceptC1 - which is set at startup in the terminal, and never reset anywhere. Then the test in the state machine just becomes:

_parserMode.any(Mode::AcceptC1, Mode::AlwaysAcceptC1)

It's a bit hacky, but that should add no significant overhead, and we won't then have to care what AcceptC1 might be set to.

@j4james commented on GitHub (Sep 11, 2022): I think this may be another regression from #13024. When we first added support for `DECAC1` in #11690, the assumption was that it would be enabled permanently on the conpty client side, and there was nothing in the terminal code that could turn that off. However, when `TerminalDispatch` was replaced with `AdaptDispatch`, it inherited the conhost `SoftReset` implementation, and that included turning off `DECAC1`. I haven't tried this yet, but one simple fix could be to add another parser mode - something like `AlwaysAcceptC1` - which is set at startup in the terminal, and never reset anywhere. Then the test in the state machine just becomes: ``` _parserMode.any(Mode::AcceptC1, Mode::AlwaysAcceptC1) ``` It's a bit hacky, but that should add no significant overhead, and we won't then have to care what `AcceptC1` might be set to.
claunia commented 2026-01-31 06:13:38 +00:00
Author
Owner
Copy Link

@DHowett commented on GitHub (Sep 12, 2022):

Ah, this is a weird case. Great catch! Eventually we would want to turn that new "always" flag off by default, because there may not always be a guarantee that Terminal is connected to ConPTY.

I'm cool with this fix, if we file a followup/todo somewhere.

Quick question: does this mean a hard reset breaks Terminal in general? Should I crack the seal on the coming 1.15 and 1.16 releases to slip in a fix for this? 🙂

(Edit: oh, C1 isn't the common case for ConPTY. You're safe to ignore a bunch of the concerns here. Thanks!)

@DHowett commented on GitHub (Sep 12, 2022): Ah, this is a weird case. Great catch! Eventually we would want to turn that new "always" flag off by default, because there may not always be a guarantee that Terminal is connected to ConPTY. I'm cool with this fix, if we file a followup/todo somewhere. Quick question: does this mean a hard reset breaks Terminal in general? Should I crack the seal on the coming 1.15 and 1.16 releases to slip in a fix for this? 🙂 (Edit: oh, C1 isn't the common case for ConPTY. You're safe to ignore a bunch of the concerns here. Thanks!)
claunia commented 2026-01-31 06:13:39 +00:00
Author
Owner
Copy Link

@j4james commented on GitHub (Sep 12, 2022):

Eventually we would want to turn that new "always" flag off by default, because there may not always be a guarantee that Terminal is connected to ConPTY.

Yeah. We've actually already got a comment in the code at that point.
d11ea72639/src/cascadia/TerminalCore/Terminal.cpp (L88-L89)

Quick question: does this mean a hard reset breaks Terminal in general?

Only if someone is actually using C1 controls, which requires actively enabling them with DECAC1. So I don't it's that big a deal, but I do know at least one application that is doing that (see 26a40a1a45).

@j4james commented on GitHub (Sep 12, 2022): > Eventually we would want to turn that new "always" flag off by default, because there may not always be a guarantee that Terminal is connected to ConPTY. Yeah. We've actually already got a comment in the code at that point. https://github.com/microsoft/terminal/blob/d11ea7263916c52106c91e57bf44398430664b9a/src/cascadia/TerminalCore/Terminal.cpp#L88-L89 > Quick question: does this mean a hard reset breaks Terminal in general? Only if someone is actually using C1 controls, which requires actively enabling them with `DECAC1`. So I don't it's that big a deal, but I do know at least one application that is doing that (see https://github.com/microsoft/DbgShell/commit/26a40a1a457eb25be55ad9a29e19bdc1ee06d5d4).
claunia commented 2026-01-31 06:13:39 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 14, 2022):

:tada:This issue was addressed in #13969, which has now been successfully released as Windows Terminal v1.15.3465.0 and v1.15.3466.0.🎉

Handy links:

@ghost commented on GitHub (Dec 14, 2022): :tada:This issue was addressed in #13969, which has now been successfully released as `Windows Terminal v1.15.3465.0 and v1.15.3466.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.15.3466.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
claunia commented 2026-01-31 06:13:39 +00:00
Author
Owner
Copy Link

@ghost commented on GitHub (Dec 14, 2022):

:tada:This issue was addressed in #13969, which has now been successfully released as Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0.🎉

Handy links:

@ghost commented on GitHub (Dec 14, 2022): :tada:This issue was addressed in #13969, which has now been successfully released as `Windows Terminal Preview v1.16.3463.0 and v1.16.3464.0`.:tada: Handy links: * [Release Notes](https://github.com/microsoft/terminal/releases/tag/v1.16.3464.0) * [Store Download](https://www.microsoft.com/store/apps/9n8g5rfz9xk3?cid=storebadge&ocid=badge)
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 Issue-Bug Needs-Tag-Fix Needs-Triage Resolution-Fix-Committed
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#18425
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?