In windows HCM we report "forced-colors: requested" even in chrome
(where we're technically not forcing colors). We want to use the HCM
mode in this case.
Differential Revision: https://phabricator.services.mozilla.com/D241478
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
This patch changes the backing prefs by relying on the tristate offered
by browser.display.document_color_use instead of
browser.display.use_system_colors. This simplifies the color
decision tree, and offers a simplified UI.
The tristate preference offered to the user is as follows:
1. "Use platform's contrast settings" (document_color_use=0)
2. "Off" - never use HCM, regardless of platform setting (document_color_use=1)
3. "On" - always use HCM, regardless of platform setting (document_color_use=2)
Option 3 also reveals a colors UI for the user to choose the palette the
browser HCM will use (bg/text/link/visited).
There are three color palettes to choose from in light of the preference
above they are:
1. WIDGET_COLORS: The OS's configured colors used by its theme.
2. HARDCODED_COLORS: Colors deemed as standard and are hard coded into
Firefox (eg. white on black text, blue and purple links).
3. PREFERENCE_COLORS: Colors that are stored in preferences and are
configurable from the colors UI (eg. browser.visited_color and
browser.display.background_color)
The decision over which palette to use is as follows:
* If we are styling browser UI -> WIDGET_COLORS
* else, if resist fingerprinting is enabled -> HARDCODED_COLORS
* else, if document_color_use==0 AND OS HCM is on -> WIDGET_COLORS
* else, if document_color_use==2 -> PREFERENCE_COLORS
* else -> HARDCODED_COLORS
Differential Revision: https://phabricator.services.mozilla.com/D211115
Instead of relying on the embedder color-scheme directly, use the
color-scheme property to determine the nsCocoaWindow's appearance.
This is more in line with what content does, would've prevented this bug
from existing altogether, and avoids the need for MOZGlobalAppearance.
Differential Revision: https://phabricator.services.mozilla.com/D207050
Make it account for stuff like ui.systemUsesDarkTheme, otherwise the
chrome and macOS may have a different idea about what the global
appearance is.
Remove observer from nsLookAndFeel. Nothing in nsLookAndFeel reads from
MOZGlobalAppearance, and we want the MOZGlobalAppearance to derive from
nsLookAndFeel, not the other way around.
Differential Revision: https://phabricator.services.mozilla.com/D207049
This requires moving some code around to PreferenceSheet, but that makes
stuff actually a bit simpler.
Depends on D192574
Differential Revision: https://phabricator.services.mozilla.com/D192575
We might want to do this more generally at the PreferencesSheet level
all the times we're forcing colors, but this should be uncontroversial
and fix the default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D192574
Instead, use forced-color-adjust: none to disable HCM forced colors in
DevTools, for now. It's a more straight-forward way of doing it.
Differential Revision: https://phabricator.services.mozilla.com/D192669
These days, after bug 1853323, about:PreferenceStyleSheet is basically
just an empty sheet for most users. For the ones that isn't, it's either
slightly or completely broken (see below).
If we were to implement this today, we'd do it with privileged env()
variables or media queries, and add a bunch of tests for different
combinations, but I don't think it's worth the effort:
* There's no UI for any of these prefs.
* There are no tests for any of these prefs.
* browser.display.focus_ring_or_anything is not great, it's better
replaced by browser.display.show_focus_rings, which actually makes
the :focus-visible pseudo-class work. Otherwise the native controls
may show no rings even though this pref is set.
* for browser.display.focus_ring_style = 0, the color used
(-moz-mac-focusring) is not implemented in any non-macOS platform.
* The ::-moz-focus-inner rules are completely useless nowadays, because
::-moz-focus-inner only works on the windows native theme (which
isn't used on content).
* The focus colors are not color-scheme aware.
So given those, and that if you want the specific current behavior,
these are trivially implementable as a web extension (by using a user
stylesheet), I think we should just remove this code altogether.
Differential Revision: https://phabricator.services.mozilla.com/D190464
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
This patch is a bit bigger than I'd like, but it's mostly moving code
around to centralize the color/color-scheme decisions we make when
forcing colors.
In practice, the only behavior change should be that when "use system
colors" is false and we force colors, we force a color-scheme that
matches the user-chosen background (via the LookAndFeel::IsDarkColor
check).
That should make sure that text from system colors is light and matches
the user expectations.
Before this patch, we used to force the color-scheme to light, but that
was just so that we ended up looking at mLightColors. Instead, we
achieve that via a separate bit (mForcedLightColorSet, naming up for
debate, not a fan), so that we can use the right system colors
otherwise.
Another alternative I considered is making all non-link system colors
return mDefaultBackground / mDefault depending on whether they are
background / foreground colors. That seemed a lot more work and
potentially a regression in various ways. I think this should be
strictly an improvement instead.
Differential Revision: https://phabricator.services.mozilla.com/D142423
For that:
* Tweak the standin system colors to match the non-native theme.
* Use those system colors for button and field backgrounds.
* Rename the "should use system colors" bit to "is high contrast",
which is what it really is (specially now that we use system colors
also in non-high-contrast).
Border colors and other colors like the <input type=range> and such
might need some extra tweaking perhaps, but this is a decent start and
looks good in https://crisal.io/tmp/form-controls.html afaict (dark mode
toggle needs the color-scheme pref enabled of course).
Differential Revision: https://phabricator.services.mozilla.com/D127533
Remove the need to post a runnable to coalesce them (we still coalesce
theme changes because those do non-trivial work).
What can go on is that on cold load we load the font list async, and
that goes through this code via a faked font.internaluseonly.changed
pref change, which stores a reframe change hint in
mChangeHintForPrefChange.
If the page flushes after this code runs, but before the next refresh
driver tick, we will be just wasting work. So instead do the
RebuildAllStyleData call synchronously. It just schedules a flush and
posts a hint, so it doesn't do the work right there, but makes the next
flush do the work as needed, so it should be faster and also more
correct.
Also improve handling of preference sheet prefs and such to avoid more
wasted work when we go through this code, as the assumption their
handling was doing was that it gets called infrequently, but it's not
the case due to the font list updates.
Differential Revision: https://phabricator.services.mozilla.com/D123103
Previously, we only respected the user's system colors preference in the case that a user (a) was not using a high contrast theme or (b) was using the high contrast theme supplied by firefox (FF-HCM).
Any OS-level HCM forced system colors and rendered the checkbox non-functional. We also previously computed visited link color via foreground/background composition, but this is only necessary on Windows HCM where the theme fails to specify a visited link color.
Differential Revision: https://phabricator.services.mozilla.com/D119814
Instead, use default colors.
Testing this properly requires writing test infrastructure for paged tests with
"print backgrounds" settings turned off, not sure if worth it.
Depends on D120679
Differential Revision: https://phabricator.services.mozilla.com/D120680
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
Sylvestre Ledru