starred/terminal
1
0
Fork 0
mirror of https://github.com/microsoft/terminal.git synced 2026-07-08 18:16:28 +00:00
Code Issues 19.0k Packages Projects Releases 20 Wiki Activity

Custom default colors are problematic for legacy apps #8202

New Issue
Open
opened 2026-01-31 01:23:18 +00:00 by claunia · 0 comments
claunia commented 2026-01-31 01:23:18 +00:00
Owner
Copy Link

Originally created by @j4james on GitHub (May 17, 2020).

Environment

Windows build number: Version 10.0.18362.719
Windows Terminal version (if applicable): commit b46d393061

Steps to reproduce

  1. Build a recent version of the OpenConsole solution.
  2. From the tools directory run opencon, to get a cmd shell.
  3. Open the Properties dialog and set the Screen Background to color index 3 (cyan).
  4. And on the Terminal tab, check Use Separate Background, and set some shade of red, e.g. 100/0/0.
  5. Execute cls.

Expected behavior

I'd expect the screen to be cleared with the same colors used to render the prompt. This is what it looks like in my existing Windows cmd shell.

image

Actual behavior

The screen is cleared with a cyan background, while the prompt is rendered with a red background.

image

The problem here is the active background color has ColorType::IsDefault, but the console APIs only deal in legacy attributes, which can't represent a "default" color. So when cls looks up the active background color, the legacy API returns the Screen Background index, which is cyan. And that's the color that cls then uses to fill the screen. The prompt in the meantime is just using the active background color, which is a genuine default color that maps to red.

The reason why this used to work, is the FillConsoleOutputAttribute API had a hack (since removed in PR #3100) that magically converted a legacy color that matched the legacy version of the active color into that equivalent TextColor value. However, that only applied when VT mode was enabled, so it wouldn't work for most legacy apps, and also relied on the active color just happening to match the color you wanted to fill with, which is by no means guaranteed.

So one option is we could add that hack back (or something similar), but I don't think that's the right solution. Other than the limitations mentioned already, it's only solving part of the problem. I know from working on issue #2661 that this is likely to effect us in other ways once conpty is passing through the full attributes correctly (the fact that conpty maps black to default is actually shielding us from these issues).

I have an idea for how we might address this, but I wanted to think it through some more before writing up the details. In the meantime, though, I thought it best to get this issue filed so you're at least aware of the problem.

Originally created by @j4james on GitHub (May 17, 2020). # Environment Windows build number: Version 10.0.18362.719 Windows Terminal version (if applicable): commit b46d39306124363a4104afb74fa9b6657b1d17d0 # Steps to reproduce 1. Build a recent version of the _OpenConsole_ solution. 2. From the _tools_ directory run `opencon`, to get a cmd shell. 3. Open the _Properties_ dialog and set the _Screen Background_ to color index 3 (cyan). 4. And on the _Terminal_ tab, check _Use Separate Background_, and set some shade of red, e.g. 100/0/0. 5. Execute `cls`. # Expected behavior I'd expect the screen to be cleared with the same colors used to render the prompt. This is what it looks like in my existing Windows cmd shell. ![image](https://user-images.githubusercontent.com/4181424/82157346-d11c1f00-9878-11ea-96a6-ae8ad3571d98.png) # Actual behavior The screen is cleared with a cyan background, while the prompt is rendered with a red background. ![image](https://user-images.githubusercontent.com/4181424/82157349-d7120000-9878-11ea-8dcf-7f26de717bae.png) The problem here is the active background color has `ColorType::IsDefault`, but the console APIs only deal in legacy attributes, which can't represent a "default" color. So when `cls` looks up the active background color, the legacy API returns the _Screen Background_ index, which is cyan. And that's the color that `cls` then uses to fill the screen. The prompt in the meantime is just using the active background color, which is a genuine default color that maps to red. The reason why this used to work, is the `FillConsoleOutputAttribute` API had a hack (since removed in PR #3100) that magically converted a legacy color that matched the legacy version of the active color into that equivalent `TextColor` value. However, that only applied when VT mode was enabled, so it wouldn't work for most legacy apps, and also relied on the active color just happening to match the color you wanted to fill with, which is by no means guaranteed. So one option is we could add that hack back (or something similar), but I don't think that's the right solution. Other than the limitations mentioned already, it's only solving part of the problem. I know from working on issue #2661 that this is likely to effect us in other ways once conpty is passing through the full attributes correctly (the fact that conpty maps black to default is actually shielding us from these issues). I have an idea for how we might address this, but I wanted to think it through some more before writing up the details. In the meantime, though, I thought it best to get this issue filed so you're at least aware of the problem.
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-Server Area-UserInterface Impact-Correctness Issue-Bug Needs-Tag-Fix Priority-3 Product-Conhost 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#8202
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?