Firefox 146 ignores the toolbar theme (light, dark, or custom) when Windows High Contrast mode is enabled, even if the Firefox setting "Contrast Control" is set to "Off"
Categories
(Firefox :: Theme, defect)
Tracking
()
People
(Reporter: dimedr, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:146.0) Gecko/20100101 Firefox/146.0
Steps to reproduce:
Updated firefox from 145 to 146.
Actual results:
Got ugly and unchangeable "High Contrast" toolbar theme.
Expected results:
Nothing.
|
||
Comment 1•7 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Firefox::Theme' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Comment 2•7 months ago
|
||
Same on Windows 11 22621.1485 here.
One can see the theme prefs inside about:config change from 1 to 2 on a theme-by-theme basis, but they never respect the values inputted to them. Also worth noting is that browser.theme.toolbar-theme seems to have an in-between state, where right after changing themes it gets assigned value 0. After a couple more seconds, it is then assigned the target value.
i.e.: 1 -> 0 -> 2 or 2 -> 0 -> 1. Same thing when the browser starts up: browser.theme.toolbar-theme starts at value 0 and only a bit later is it initialized to the real target value.
|
|
||
Comment 3•6 months ago
|
||
The severity field is not set for this bug.
:mstriemer, could you have a look please?
For more information, please visit BugBot documentation.
|
||
Updated•6 months ago
|
|
||
Comment 4•6 months ago
|
||
Hi, thanks for the bug report. This is actually working as intended, and not a bug.
In bug 1988635, which shipped in Firefox 146, we disabled themes in high contrast mode. The intent here was to give users with accessibility needs a consistent experience. As discussed in that earlier bug, attempting to mix Firefox theme colors and the forced-colors palette was the root cause for a large number of accessibility bugs caused by inconsistently mixing the forced-colors palette and theme colors. We also continually created new accessibility bugs because any new UI component would need to add forced-colors support, and this is simply difficult to do correctly.
We anticipated that some users and some workflows might become broken when this shipped, so we added a pref to disable this new behavior in bug 1997455. You can revert to the old behavior by visiting about:config and setting the pref browser.theme.forced-colors-override.enabled to false (However, this pref might eventually be removed--it was really added in case a huge number of users ran into problems, so that we could disable the new behavior remotely.)
We are keeping track of users who are unhappy with the change in behavior, as we might refine the forced-colors behavior further in the future. So, while I'm going to WONTFIX this bug, I'll add this to the existing metabug 1988629.
(In reply to Jared Hirsch [:jhirsch] (he/him) (Needinfo please) from comment #4)
I think for Firefox, this behavior should fully depend on the existing "Contrast Control" setting, not be hardcoded. If it is set to "Off", it should be off; if set to "Custom", it should follow the custom values. This setting exists for a reason.
|
|
||
Comment 6•6 months ago
|
||
Thanks for your suggestion. Note that Contrast Control changes web content, not the browser UI. You can read more about it here: https://support.mozilla.org/en-US/kb/firefox-contrast-control
If you'd like to customize the colors in Firefox, you can either customize your OS contrast theme, or you can flip the pref mentioned in my last comment and revert to the old behavior, inconsistently mixing Firefox theme and contrast theme colors.
Yeah, I already switched. In the worst case, I can also use userChrome.css. It just bugs me a bit that we now lose the ability to customize the UI using normal settings.
Description
•