UI is broken in system high contrast mode

[mimi89999]

Environment

Windows build number: 10.0.19603.1000
Windows Terminal version (if applicable): 0.10.781.0

Steps to reproduce

Turn on high contrast mode.

Expected behavior

UI elements should become easier to distinguish.

Actual behavior

Terminal UI elements are hard to identify. It took me some time to find the + button because it looks like the Windows logo or the start menu button and not like a +. Dropdown button looks more like a checkbox than a dropdown button or arrow pointing down.

[zadjii-msft]

Okay yea this is pretty bad. I would have thought that this might have to be fixed on the upstream TabView. However, looking at MUX#1663, that high-contrast tabview looks just fine.

[zadjii-msft]

Wait now I'm reading that thread more, we might be able to get this by just updating to the latest MUX.

This comment: microsoft/microsoft-ui-xaml#1663 (comment) made me think that they might have just solved this for us 😆

[jtippet]

@zadjii-msft - I just stopped by the Terminal github project to send you guys an email to ask you to update to the latest MUX, so I can start contributing some PRs to smooth out Terminal's HC experience. I promise mimi8999 is not in cahoots with me, and this issue getting filed today is a total coincidence ;)

XAML has a global "I understand high contrast" flag named ApplicationHighContrastAdjustment. For Terminal, it's currently in HC-ignorant mode, which means MUX is more aggressive about ignoring your colors and automatically backplating text. This is not wrong, but it will make it difficult to reach perfect beauty. Beyond updating MUX, the next best thing you can do is toggle that flag, then fix the issues that it was hiding (invisible dialog box buttons, menu text, wrong titlebar color, etc.)

I'm happy to contribute wherever you can use help -- the whole reason I fixed MUX's TabView was so I could subsequently make my terminals not ugly.

[mimi89999]

@jtippet Were you able to build Terminal with latest MUX release? I wasn't.

[jtippet]

I didn't attempt that. I've only prototyped the other half - cleaning up button labels and menu text.

[DHowett-MSFT]

Triaging this for 1.x. If WinUI 2.4 lands before that, we may get it as part of a dependency updating pass.

[WSLUser]

Since I was looking into bumping deps, I did try updating to the preview release (we are actually on a 2.2. preview so going to 2.4 preview seems acceptable) but ran into problems attempting to build. I can update the other stuff but while debug mode is fine, the release mode has an issue compiling conpty in preview mode of VS 2019 and a problem finding the generated .lib in stable. Not sure what exactly is at play but my fork is available to test with. Also, you need to statically assign paths for instead of using wildcards in the build process. VS2019 won't accept the wildcards (building Terminal becomes even worse without letting VS statically assign the build paths).

[DHowett-MSFT]

Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we need that copy of their DLL.

Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

[DHowett-MSFT]

Thanks for looking into this! I’m a bit concerned. We are using 2.3, for what it’s worth, and even though it says “prerelease” it’s definitely the full retail payload. There’s a depressing reason for that... but in short, the “prerelease” builds put their DLLs inside our package, and the retail ones do not, and we need that copy of their DLL.

Which version of VS2019 are you seeing this with? The team has been building on 2019 since it came out, and hasn’t seen any trouble with the wildcards.

[jtippet]

@DHowett-MSFT - may I request updating MUX again to 2.5.0-prerelease.200609001? That version contains a couple important fixes to unblock a fix for this issue:

• Fix background of MenuFlyout in white high contrast microsoft-ui-xaml#2446
• Improve readability of AccentButton style on High Contrast microsoft-ui-xaml#2377

With that version of MUX, Terminal is very close to being beautiful in all HC themes. Here's a peek at what it looks like with the newer MUX and a change to set Terminal to ApplicationHighContrastAdjustment::None:

Compare that to the screenshot at the top of this thread, and I think it's clearly an improvement. The menu is rather less embarrassing too:

Current	2.5.0 + AHCA::None

As a bonus, by updating to 2.5.0, you'll also get rounded tab feet, which is catnip for tab nerds:

[mimi89999]

Is there any progress on this issue? The latest preview from the Store still looks really bad

[mimi89999]

Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why?

[zadjii-msft]

@jtippet absolutely lets update! Kinda funny that we only just got on 2.4 (#5778) a few days before the 2.5 prerelease came out 😃

[jtippet]

Is there any progress on this issue? The latest preview from the Store still looks really bad

There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared.

Also, I noticed that some icons in the taskbar change to monochrome and others don't. Why?

The OS never automatically generates monochrome icons from a full-color icon. It would rarely look great, and in some cases, would make an unreadable mess.

For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has the technology to designate an icon as being for high contrast -- classic win32 resources don't even have the concept. (Classic win32 can only tailor icons for display scale and color bitdepth, the latter of which is entirely obsolete, since nobody's rocking an EGA display anymore.) So a UWP app can display colorful icons when HC is disabled, while automatically switching to monochrome icons when HC is enabled. But a Win32 app has to choose one or the other, and can't adapt to the HC setting. That's why, in your screenshot, the File Explorer icon is not monochrome: File Explorer is a win32 app.

Furthermore, an app will only change its icon if the app developer's art department actually troubled themselves to provide a high contrast version of the icon. That's why, in your screenshot, Terminal does not have a monochrome icon: the Terminal art department did not provide one. Although if you have more pixel talents than I, perhaps the Terminal team would accept a contribution of beautiful new HC icons? See here.

Hopefully, as Project Reunion makes UWP technology more readily available, more developers will include high contrast icons with their apps.

[mimi89999]

There's definitely been progress -- comparing your original screenshot with your current one, you can see that the tab titles look better. That's fix 1663 in MUX, which already shipped in the store version of Terminal. The menu will be improved a bit once #6819 lands, and then there's really only one more line of code to add to Terminal to make everything look like the screenshot I shared.

Ah. OK. I see that the tabs look good now, but the + and arrow down buttons still have a background. I thought that they also would be fixed since in the animation in microsoft/microsoft-ui-xaml#1663 (comment) those buttons also don't have the background anymore.

For the app launcher icons in the center of the taskbar, the shell relies on the app to provide a hand-crafted high contrast icon. But only UWP has the technology to designate an icon as being for high contrast...

Thanks for this long explanation. Hopefully Terminal will get a monochrome icon soon 😉
As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer. AFAIK only Explorer and Recorder are using it. Somebody managed to enable it: https:/ysc3839/win32-darkmode. Maybe they will do the same for icons? I don't see them anywhere close to rewriting old Win32 apps. Anyway, that's off topic here...

[jtippet]

I thought that they also would be fixed since in the animation in microsoft/microsoft-ui-xaml#1663 (comment) those buttons also don't have the background anymore.

Yeah, I fixed the standard TabView [+] icon that ships with MUX. But Terminal doesn't use the standard icon. It builds its own from scratch, so it can have the dropdown menu. Don't worry though: I'm fixing Terminal's [+] button too: #6812

As for old Win32 apps, I saw that MS made a nonofficial API for dark theme especially for Explorer.

You can definitely write code to detect whether HC is enabled, and if so, query the background color. You don't even need undocumented APIs -- just query SPI_GETHIGHCONTRAST. So you can already write a win32 app that draws a beautiful icon in all modes. But the taskbar problem that you're seeing is different: the app isn't drawing the icons, so there's no amount of code you can add to the app to fix the problem. There are various OS surfaces (taskbar, start menu, alt+tab, task manager, ...) where the OS draws an icon on behalf of your app. In those cases, the OS needs to know which of your icons to use. UWP has a sophisticated metadata system, so for example you can describe an icon as being designed for 200% DPI + high contrast black theme + fr_CA locale. The OS will inventory all your icons, sift through the metadata, then select the best icon for the current situation. Compare that to Win32, where the icon can only talk about pixels and color depth -- there's simply no way for you to say that a particular icon is designed to look great in HC black theme.

[ghost]

🎉This issue was addressed in #6915, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #6915, which has now been successfully released as Windows Terminal v1.1.2021.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #6915, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

• Release Notes
• Store Download

[ghost]

🎉This issue was addressed in #6833, which has now been successfully released as Windows Terminal Preview v1.2.2022.0.:tada:

Handy links:

• Release Notes
• Store Download