User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.135 Safari/537.36 Edg/84.0.522.63

Steps to reproduce:

1. Enable high-contrast mode in Windows 10, by doing the following:
   1.1. Open Windows Settings (Windows+I).
   1.2. Go to Ease of access -> High-contrast.
   1.3. Turn on the high-contrast mode, using the respective toggle.
   1.4. From the "High-contrast theme" combo-box, select "High-Contrast Black".
2. Install and launch Thunderbird 78.2.

Actual results:

Observe how some dialogs and windows of Thunderbird do not obey the colors defined by the currently active high-contrast black theme. Mostly, where the background should be black, it is gray instead. I'll attach some example screenshots in a ZIP archive.

Examples of such windows include, but may not be limited to, the following:

• The main window of Thunderbird.
• The dialogs for subscribing to IMAP folders and RSS feeds.
• The dialogs for the properties of RSS and mail folders.
• The dialog for customizing the toolbars in Thunderbird.
• The dialog for creating a new folder.
• The dialog/window for adding an account to Thunderbird.

Expected results:

In such dialogs and windows as in the examples above, the background color should be black, instead of being gray as it is now.

Kostadin,
Is this now worse when using 78 compared to 68?

Wayne,

Yes, it is worse. Actually, it is worse even when compared with v78.1.1.

It looks like this is a fallout of bug 1638233. It detects a dark theme and sets the pref ui.systemUsesDarkTheme for dark themes. When I change first to a light theme (because of the issue with not going back to default when only enabling the default theme) and then set the default theme, the display is correct again - until I restart TB.

Alessandro, could we somehow detect the high contrast theme and then not set the ui.systemUsesDarkTheme? Or could we on Windows only check the theme when a TB theme is selected?

Alessandro, could we somehow detect the high contrast theme and then not set the ui.systemUsesDarkTheme? Or could we on Windows only check the theme when a TB theme is selected?

I'm not sure it's possible, but it'll look into it.

Maybe the pref extensions.activeThemeID could be checked.

The extensions.activeThemeID pref always returns "default-theme@mozilla.org", regardless if the windows theme is high contrast or not.
This problem doesn't happen on Ubuntu with the inverted High Contrast system theme, as all those backgrounds are black and not grey even if the ui.systemUsesDarkTheme is set to 1.
This seems to be a Windows specific thing.
I'll keep investigating.

Once thing I noticed is the color of the selected item in the folder tree is black when using High Contrast Black and ui.systemUsesDarkTheme set to 1.

I can recreate the issue reported only if I manually set the theme to Dark in the Add-ons panel.
Kostadin, are you sure you don't have the Dark Theme enabled in Thunderbird? The theme should be set to Default to let the High Contrast System Theme overwrite everything.

Hello Alessandro,

I just checked to be sure, but no - the dark theme is not set as the default one in Extensions -> Themes. The theme set as the default is the standart/default one - it is the one enabled and the light and dark ones are disabled.

Here's a first patch trying to fix this and keep the dynamic switch of the ui.systemUsesDarkTheme only when necessary.
Restarting TB at every system theme change is necessary.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/812c3ef64b09
Fix toggle of ui.systemUsesDarkTheme for High Contrast theme. r=Paenglab DONTBUILD

This needs to land on 78, but since it touches the dark theme variation I'd like to gather as many feedback as possible from Windows and macOS users.
Should we uplift this to beta and ask for feedback?

Comment on attachment 9172306 [details] [diff] [review]
1661229-high-contrast.diff

[Approval Request Comment]
Regression caused by (bug #): bug 1638233
User impact if declined: Windows and macOS users will get a wrong colour scheme when using an inverse high contrast system theme.
Testing completed (on c-c, etc.): landed on c-c and tested by Aleca and Paenglab
Risk to taking this patch (and alternatives if risky): it should be low and it's necessary to allow further testing and feedback before uplifting to 78.

I see a problem with the actual implementation: On Mac/Windows when the default TB theme is set, ui.systemUsesDarkTheme is still set, normally to 0. But this prevents to follow the system theme. With dark system theme TB still uses the light theme because ui.systemUsesDarkTheme is set to 0. We should remove the pref completely (or set to -1 but I'm not sure this works) on Mac/Windows when the default theme is used and only set it when a TB theme != default is used. Then TB can adapt to the Mac/Windows system theme again.

I removed the comm-beta flag to prevent uplifting.
So, instead of setting that pref to 0, we should remove it entirely...let's see if it's possible.

Comment on attachment 9172756 [details] [diff] [review]
1661229-remove-pref.diff

This still doesn't work. It seems the changes from bug 1638233 oversteer the detection of the system theme. Tested on Mac and Windows.

All right, let's better analyze the conditions that we need to cover and how to handle this properly.

Linux
We need to set ui.systemUsesDarkTheme to 0 or 1 based on the color contrast in order to properly adapt the UI to respect both System Theme and Thunderbird theme.
The patch as it is works as expected on Linux, other than the usual restart necessary when switching from Dark to Default, but that's for bug 1659282.

Windows and macOS
These are the conditions we need to cover:

• Thunderbird on Default theme, System on Default theme: REMOVE ui.systemUsesDarkTheme.
• Thunderbird on Default theme, System on Dark theme: ui.systemUsesDarkTheme to 1.
• Thunderbird on Default theme, System on High contrast inverse: ui.systemUsesDarkTheme to 1.
• Thunderbird on Dark theme, System on any theme: ui.systemUsesDarkTheme to 1.
• Thunderbird on another theme, System on any theme: REMOVE ui.systemUsesDarkTheme.

Is this correct?

(In reply to Alessandro Castellani (:aleca) from comment #20)

Windows and macOS
These are the conditions we need to cover:

• Thunderbird on Default theme, System on Default theme: REMOVE ui.systemUsesDarkTheme.
• Thunderbird on Default theme, System on Dark theme: ui.systemUsesDarkTheme to 1.
• Thunderbird on Default theme, System on High contrast inverse: ui.systemUsesDarkTheme to 1.
• Thunderbird on Dark theme, System on any theme: ui.systemUsesDarkTheme to 1.
• Thunderbird on another theme, System on any theme: REMOVE ui.systemUsesDarkTheme.

Is this correct?

I think not.

• When Thunderbird is on Default theme, then ui.systemUsesDarkTheme must be removed. Then TB should be able to adapt to the system theme.
• When Thunderbird is on another theme, then ui.systemUsesDarkTheme should be set depending the contrast like on Linux.

Maybe before you begin to test for the contrast you need to remove ui.systemUsesDarkTheme to not make TB to use the wrong contrast because of the pref set from the last run of TB.

(In reply to Richard Marti (:Paenglab) from comment #21)

• When Thunderbird is on Default theme, then ui.systemUsesDarkTheme must be removed. Then TB should be able to adapt to the system theme.

This won't work for Linux as a Dark System theme can't adapt the whole UI and we need to force the ui.systemUsesDarkTheme to 1.

• When Thunderbird is on another theme, then ui.systemUsesDarkTheme should be set depending the contrast like on Linux.

And this also for Windows and macOS?

Maybe before you begin to test for the contrast you need to remove ui.systemUsesDarkTheme to not make TB to use the wrong contrast because of the pref set from the last run of TB.

I'm not sure that's necessary as the processColor() method runs on launch when the ui.systemUsesDarkTheme is not set yet as we don't permanently store that.

(In reply to Richard Marti (:Paenglab) from comment #21)

I think not.

• When Thunderbird is on Default theme, then ui.systemUsesDarkTheme must be removed. Then TB should be able to adapt to the system theme.
• When Thunderbird is on another theme, then ui.systemUsesDarkTheme should be set depending the contrast like on Linux.

These points are for Mac and Windows only.

This seems to work for me.
Also, I'm not sure if it's just a random coincidence, but it seems to fix bug 1659282, at least on Linux.

Comment on attachment 9173239 [details] [diff] [review]
1661229-remove-pref.diff

It removes now the pref but with the dark system theme UI is partly dark but all UI that is based on lwt-tree-brighttext is light because this is now never set.

Have you tested it on Mac? You would notice it immediately.

This works for me on all platforms. Maybe you could make my changes nicer programmed.

Bug 1659282 isn't fixed for me on Mac/Windows when the light system theme is active and I switch from dark TB theme to default. Then ui.systemUsesDarkTheme isn't removed or set to 0.

Comment on attachment 9173412 [details] [diff] [review]
1661229-remove-pref.diff

Yes, this works now. Sorry to not catching it the first time. These in a with the previous patch combined patch needs to go ESR too.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/cf64905f6677
Remove the ui.systemUsesDarkTheme pref when forcing a colour scheme is not necessary. r=Paenglab

Comment on attachment 9172306 [details] [diff] [review]
1661229-high-contrast.diff

[Approval Request Comment]
Regression caused by (bug #): bug 1638233
User impact if declined: Windows and macOS users will experience theme inconsistencies when relying on the OS theme settings.
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

INFO: Both uploaded patches need to be uplifted at the same time.

Comment on attachment 9173412 [details] [diff] [review]
1661229-remove-pref.diff

[Approval Request Comment]
Same as the previous comment.
Both patches need to be uplifted at the same time.

Comment on attachment 9172306 [details] [diff] [review]
1661229-high-contrast.diff

[Triage Comment]
Taking for 81.0b3.

Comment on attachment 9173412 [details] [diff] [review]
1661229-remove-pref.diff

[Triage Comment]
Taking for 81.0b3

Thunderbird 81.0b3:
https://hg.mozilla.org/releases/comm-beta/rev/3cccd99d46f2
https://hg.mozilla.org/releases/comm-beta/rev/e88d729a2437

Comment on attachment 9172306 [details] [diff] [review]
1661229-high-contrast.diff

[Approval Request Comment]
Regression caused by (bug #): bug 1638233
User impact if declined: Windows and macOS users will experience theme inconsistencies when relying on the OS theme settings.
Testing completed (on c-c, etc.): on c-c and beta
Risk to taking this patch (and alternatives if risky): low

INFO: Both uploaded patches need to be uplifted at the same time.

Comment on attachment 9173412 [details] [diff] [review]
1661229-remove-pref.diff

[Approval Request Comment]
Same as the previous comment.
Both patches need to be uplifted at the same time.

Please confirm Fix will work in:
General UI (Folder Pane, thread Pane), All Menus and Toolbars (tooltips seem ok) Write window, Address Book and also Calendar, Tasks, Events, Today Pane as these areas are currently not showing High Contrast.

eg: Write window : Green thin outline on TO and Cc etc if selected, otherwise they fade to soft white on grey, Formatting bar icons green until you focus on content area, then turn to white. All toolbars, From text etc all white.
Choice of default font colour is set as yellow on black, but yellow auto changes to white when select content area to type and background is not black it's grey.
So no High Contrast or very poor.
'Save Message' pop up is OK.

Hover over items in Menu Bar - green All right click options and Toolbar drop down selection have green over selected.
Hover over Mail Toolbar or Quick Filter Bar - pale grey - no high contrast.
Select 'Menu app icon' and all menu sub lists therein all pale on greys - no high contrast.

I have a Support Forum impaired vision query and they are struggling with 78.2.1
Will this fix be in the next release update?

Comment on attachment 9173412 [details] [diff] [review]
1661229-remove-pref.diff

[Triage Comment]
Approved for esr78.

Comment on attachment 9172306 [details] [diff] [review]
1661229-high-contrast.diff

[Triage Comment]
Approved for esr78.

Thunderbird 78.2.2:
https://hg.mozilla.org/releases/comm-esr78/rev/ee9c40921062
https://hg.mozilla.org/releases/comm-esr78/rev/a66331165b76

Hello,

Today I've updated to Thunderbird 78.2.2 and this seams to be only partially fixed:

In the main window of Thunderbird:

• The colors for the folder selection in the folders pane on the left are only partially fixed. The text color seams to be as it should - black - but the background should be blue and not very dark gray (or whatever that color is).
• The pane that appears on the right when account name is selected in the left is now using a light color theme instead of dark as it did before the last fix. It should obey the system color settings (in my case - black background and white text and yellow hyperlinks).
• The colors for the message selection in the messages list pane on the right are only partially fixed. The text color seams to be as it should - black - but the background should be blue and not very dark gray (or whatever that color is).

In the "Customize Toolbar" dialog:

• The colors in the "Customize Toolbars" dialog are only partially fixed. The part not fixed is the pane where the available toolbar components are listed - it still uses the dark theme colors instead of the ones provided by the system (in my case - white text and black background).

I can provide screenshots, but I don't see a way to attach them with my comment. Or is it because the bug is closed for the moment (?).

OK, now that I've reopened the bug, I can attach files to it.

This fixes the issues. In account central I used system colours when a high contrast theme is used on Windows and no theme is selected. On Windows 7 this applies to the classic theme too because we can't differentiate between them.

What I haven't changed are the colours of thefolder pane icons. Maybe we can do this in a follow-up bug.

How it looks. The "Newsgroup" button is hovered.

What I haven't changed are the colours of the folder pane icons. Maybe we can do this in a follow-up bug.

Yes, that sounds good.

(In reply to Alessandro Castellani (:aleca) from comment #48)

Comment on attachment 9175286 [details] [diff] [review]
1661229-high-contrast-rules.patch

Review of attachment 9175286 [details] [diff] [review]:

This looks good, but I'd like a secondary review from someone that can
compile daily or 78 on Windows as I'm applying these changes in the
inspector on a VM.
I want to be sure this won't affect the regular Dark Theme or the Windows
Dark Mode.

I've tested it but better we have additional tests.

Maybe Thomas or Paul?

I started a try build at https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=3aa75555fef473b4c4a4067ece0903b89c1d70a0
When it finished, click on the (hopefully) green B on bottom go to Artifacts and download the target.zip or target_installer.exe to test.

I don't have a way to build on Windows (yet). Working on it though.

My first attempt of testing this with the try-build from comment 50 doesn't seem to work as expected, am not getting what Richard saw in attachment 9175287 [details].

• existing TB daily profile with dark theme set
• set Windows to high contrast
• TB try, change from dark to default theme in add-ons (partially applies)
• Restart TB to make sure

Actual result (see screenshot):

• Windows high-contrast colors not coming to 3 pane folder list and message list, looks same as TB dark theme.
• TB menus and other corners seem to have high contrast, with neon-green disabled menus (is that the default? strange)

I have experienced this before, that depending on how you switch themes around in TB, they don't seem to apply immediately as expected. Can't nail it though.

After one more restart of TB (or was it the first restart??), TB did pick up high contrast everywhere.
So then I tried TB light theme, and this is the result of applying that (even after TB restart!) - new bug?
Black buttons on message header, green on hover.
Definitely live switching of Themes doesn't work as expected.

Another nit: with Windows high Contrast and TB default theme, toolbars won't pick high contrast -> new bug?

Or maybe I'm missing something?

This is addons-tab in light theme (sic), with Windows on high-contrast.
So I understand that light or dark themes should completely override OS high contrast, right?
Apparently not the case, add-ons tab is high-contrast (not light), and app close/minimize etc. buttons too.

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/4d5f30d5e89b
Add special Windows high contrast rules. r=aleca

In fact, trouble starts on install - can't read installation dialog with Windows 10 high contrast. Does anyone else see this?

Comment on attachment 9175286 [details] [diff] [review]
1661229-high-contrast-rules.patch

[Approval Request Comment]
User impact if declined: Wrong colours in account central
Testing completed (on c-c, etc.): on c-c
Risk to taking this patch (and alternatives if risky): low

The toolbars have still enough contrast. They use the background to better differentiate from the other content.
Using themes when using high contrast desktop is a bit meaningless. Why should one need the high contrast and then set a theme that reduces or reverts the contrast?

Thomas, can you file a bug for the installer?

(In reply to Thomas D. (:thomas8) from comment #57)

Created attachment 9175975 [details]
Screenshot: TB install dialog on Win10 high contrast not readable

In fact, trouble starts on install - can't read installation dialog with Windows 10 high contrast. Does anyone else see this?

Yes, I can definitely reproduce this, but I haven't gotten around to report it. Mind you, if it matters, this was the same for Firefox, but it got fixed for it some time ago.

(In reply to Richard Marti (:Paenglab) from comment #59)

The toolbars have still enough contrast. They use the background to better differentiate from the other content.

Noble in theory, wrong in application. For our own sake, let's avoid inconsistencies and exceptions which will always backfire. In this case, not only the toolbar itself but also e.g. button hover effect on the toolbar buttons is far from "high-contrast", which violates the very purpose of this setting.
Not being able to tell apart toolbar and other content imo is an unavoidable side effect of using high-contrast. Better to err on the high-contrast side by enforcing that.

Using themes when using high contrast desktop is a bit meaningless. Why should one need the high contrast and then set a theme that reduces or reverts the contrast?

E.g. two different users on same computer, grandma not using email, but others are. It's a legitimate setting so it should just work correctly. Even if you set high contrast in OS and dark theme in TB, high contrast is not supposed to leak into TB.

Thomas, can you file a bug for the installer?

Filed, and more bugs for the other nits, too.

Comment on attachment 9175286 [details] [diff] [review]
1661229-high-contrast-rules.patch

No more betas for 81. We'll pick this up in 78.3.something

Comment on attachment 9175286 [details] [diff] [review]
1661229-high-contrast-rules.patch

[Triage Comment]
Approved for esr78

Thunderbird 78.3.2:
https://hg.mozilla.org/releases/comm-esr78/rev/9a5c9084f7c4