Make sure Terminal state machine always accepts C1 controls #13969
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
Issue-Bug
zadjii-msft
approved these changes
Sep 12, 2022
DHowett
added
the
AutoMerge
|
Hello @DHowett! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
DHowett
approved these changes
Sep 12, 2022
ghost
merged commit
DHowett
pushed a commit
that referenced
this pull request
Dec 12, 2022
When we added support for the `DECAC1` control sequence, which determines whether `C1` controls are accepted or not, the intention was that conhost would be making that determination, and Windows Terminal would always be expected to accept any passed-through `C1` controls. However, this didn't take into account that a passed-through `RIS` sequence could end up disabling `DECAC1`, and that would leave Windows Terminal incapable of processing any `C1` controls. This PR attempts to fix that oversight. The `DECAC1` sequence was added in PR #11690, when we disabled `C1` acceptance by default. This is a bit of a hack, but I've added a new `AlwaysAcceptC1` mode to the state machine, which is enabled at startup in the Terminal, and is never disabled. The parser then just needs to check whether either `AcceptC1` or `AlwaysAcceptC1` are set. ## Validation Steps Performed I've manually confirmed the test case in #13968 now works as expected. Closes #13968 (cherry picked from commit f2b361c) Service-Card-Id: 87207769 Service-Version: 1.15
DHowett
pushed a commit
that referenced
this pull request
Dec 12, 2022
When we added support for the `DECAC1` control sequence, which determines whether `C1` controls are accepted or not, the intention was that conhost would be making that determination, and Windows Terminal would always be expected to accept any passed-through `C1` controls. However, this didn't take into account that a passed-through `RIS` sequence could end up disabling `DECAC1`, and that would leave Windows Terminal incapable of processing any `C1` controls. This PR attempts to fix that oversight. The `DECAC1` sequence was added in PR #11690, when we disabled `C1` acceptance by default. This is a bit of a hack, but I've added a new `AlwaysAcceptC1` mode to the state machine, which is enabled at startup in the Terminal, and is never disabled. The parser then just needs to check whether either `AcceptC1` or `AlwaysAcceptC1` are set. ## Validation Steps Performed I've manually confirmed the test case in #13968 now works as expected. Closes #13968 (cherry picked from commit f2b361c) Service-Card-Id: 87207767 Service-Version: 1.16
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
When we added support for the
DECAC1control sequence, whichdetermines whether
C1controls are accepted or not, the intention wasthat conhost would be making that determination, and Windows Terminal
would always be expected to accept any passed-through
C1controls.However, this didn't take into account that a passed-through
RISsequence could end up disabling
DECAC1, and that would leave WindowsTerminal incapable of processing any
C1controls. This PR attempts tofix that oversight.
The
DECAC1sequence was added in PR #11690, when we disabledC1acceptance by default.
This is a bit of a hack, but I've added a new
AlwaysAcceptC1mode tothe state machine, which is enabled at startup in the Terminal, and is
never disabled. The parser then just needs to check whether either
AcceptC1orAlwaysAcceptC1are set.Validation Steps Performed
I've manually confirmed the test case in #13968 now works as expected.
Closes #13968