tmux inside an AWS SSM session forces white cursor #18695
Comments
NicosGollan-cnic
added
Issue-Bug
|
Thanks! Would you mind grabbing us the output of the debug tab? https://github.com/microsoft/terminal/wiki/Troubleshooting-Tips#enabling-the-debug-tap In particular, look out for OSC 12: |
|
Hey, thanks for the response, below is what happens when I start tmux in a gossm-initiated session, starting with the prompt where I enter "tmux". I hope that's enough since I don't exactly feel like redacting various IDs from a tonne of raw ANSI terminal :-) In particular, after sending the prompt, there appears to be this sequence before it runs off to the tmux status line, starting with the "$ " of the prompt: |
|
Hey, funny enough... this is something we expressly added support for! I see According to the big document of control sequences, this is the code for "Reset Cursor Color". Something in your remote config is requesting that we reset the cursor color. |
DHowett
added
the
Resolution-By-Design
|
FWIW,
|
|
What does it "reset to" though? By default, I have that dark blue colour everywhere, and saving settings even restores it, so my expectation would be that any "reset" would restore it to that dark colour instead of white. |
|
You know what? You're right. It's resetting to a built-in default because we don't actually fully support the reset OSC. We're tracking that over in /dup #3719, and I just started work on it (you caught me on a bored Thursday with some extra time...) |
|
Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report! |
microsoft-github-policy-service
bot
added
Resolution-Duplicate
|
For what it's worth, it looks like the Windows Console has always implemented it this way! Back in the original commit in this repository, it seems like we implemented the reset cursor color OSC by way of "set it to all white" (actually, This may not have always applied to Terminal because the console host was filtering it out. Now that there is no filtering, Terminal is exposed to a lot more... |
This pull request adds support for resetting the various color table entries and xterm resource values back to their defaults. Building on the default color table James introduced in #17879, it was relatively straightforward to add support for resetting specific entries. This implementation cleaves tightly to observed behavior in xterm(379) rather than observed behavior in libvte(0.70.6). They differ in the following ways: - xterm rejects any OSC [110..119] with any number of parameters; libvte accepts it but only resets the first color. - When passed a list of color indices to reset in 104, xterm resets any colors up until the first one which fails to parse as an integer and does _not_ reset the rest; libvte resets all parseable color indices. I was unable to verify how these reset commands interact with colors set via `DECAC Assign Color` so I went with the implementation that made the most sense: - Resetting the background color with `110` also restores the background color alias entry to its pre-`DECAC` value; this results in the perceived background color returning to e.g. index 0 in conhost and the `background` color in Terminal. - _ibid._ for the foreground color Refs #18695 Refs #17879 Closes #3719
This pull request adds support for resetting the various color table entries and xterm resource values back to their defaults. Building on the default color table James introduced in #17879, it was relatively straightforward to add support for resetting specific entries. This implementation cleaves tightly to observed behavior in xterm(379) rather than observed behavior in libvte(0.70.6). They differ in the following ways: - xterm rejects any OSC [110..119] with any number of parameters; libvte accepts it but only resets the first color. - When passed a list of color indices to reset in 104, xterm resets any colors up until the first one which fails to parse as an integer and does _not_ reset the rest; libvte resets all parseable color indices. I was unable to verify how these reset commands interact with colors set via `DECAC Assign Color` so I went with the implementation that made the most sense: - Resetting the background color with `110` also restores the background color alias entry to its pre-`DECAC` value; this results in the perceived background color returning to e.g. index 0 in conhost and the `background` color in Terminal. - _ibid._ for the foreground color Refs #18695 Refs #17879 Closes #3719 (cherry picked from commit 5f31150) Service-Card-Id: PVTI_lADOAF3p4s4AmhmQzgZOWsU Service-Version: 1.22
This pull request adds support for resetting the various color table entries and xterm resource values back to their defaults. Building on the default color table James introduced in #17879, it was relatively straightforward to add support for resetting specific entries. This implementation cleaves tightly to observed behavior in xterm(379) rather than observed behavior in libvte(0.70.6). They differ in the following ways: - xterm rejects any OSC [110..119] with any number of parameters; libvte accepts it but only resets the first color. - When passed a list of color indices to reset in 104, xterm resets any colors up until the first one which fails to parse as an integer and does _not_ reset the rest; libvte resets all parseable color indices. I was unable to verify how these reset commands interact with colors set via `DECAC Assign Color` so I went with the implementation that made the most sense: - Resetting the background color with `110` also restores the background color alias entry to its pre-`DECAC` value; this results in the perceived background color returning to e.g. index 0 in conhost and the `background` color in Terminal. - _ibid._ for the foreground color Refs #18695 Refs #17879 Closes #3719 (cherry picked from commit 5f31150) Service-Card-Id: PVTI_lADOAF3p4s4AxadtzgZOWsQ Service-Version: 1.23
Windows Terminal version
1.21.10351.0
Windows build number
10.0.26100.0
Other Software
gossm v1.5.0
tmux 3.0a
ubuntu 20.04, 22.04, 24.04
Steps to reproduce
Expected Behavior
I expect the cursor colour to remain the same. Normally, I have a dark blue cursor on a light background.
Actual Behavior
The cursor is forced to pure white when starting or terminating the tmux session.
Opening Terminal settings and saving them without any changes restores the cursor to the intended colour, and it remains that way for the remainder of the tmux session.
This does not happen when running tmux "natively" in the "parent" WSL terminal, so far I only encountered the behaviour when running tmux in an SSM session.
The text was updated successfully, but these errors were encountered: