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
This allows themes to override our light / dark theme heuristics if they
choose to, so that we don't have to complicate the heuristics too much.
This is specially useful for themes with images, where the image might
be "light", but still have enough contrast with light text. A good
example is the theme mentioned in bug 1749837 comment 0.
The semantics are:
* color_scheme: If set, overrides the general "toolbar theme" (so
window and context menu appearance and so on), otherwise we fall back
to heuristics.
* content_color_scheme: If set, overrides the color scheme for the
content area. Otherwise we fall back to color_scheme if present, or
heuristics otherwise.
One thing that I didn't include was a sort of "system" option, which
might be useful to say "this theme is neutral, and works both for light
and dark themes". Let me know if you think that's a must-have, otherwise
I think it's probably worth deferring to a follow-up if it's needed at
all.
Differential Revision: https://phabricator.services.mozilla.com/D136354
So the issue here is that GTK's nsLookAndFeel doesn't know about the
effective value of the pref, and thus ends up potentially choosing the
wrong GTK theme (and thus choosing light system colors, but thinking
that we can paint the textfield background natively with GTK, which
would have a dark background, for example).
The right fix here is treating the pref as a stronger hint than the
ColorSchemePreference that we compute from DBUS for the same purpose.
This makes us follow the same code-path as if the system had specified
dark mode itself, fixing the contrast issue.
While at it, fix dynamic changes to this pref, which need to update
system colors.
Differential Revision: https://phabricator.services.mozilla.com/D139093
We might want to do this on Windows 11 as well, but Windows 11 has a
system-wide preference with UI so let's not do that just yet at least,
UI-exposed preference.
Differential Revision: https://phabricator.services.mozilla.com/D138502
We have this situation right now where all the themes are inheriting from
nsNativeBasicTheme. Rename it to a nicer name, and clean up some code while at
it.
In the future I'd like to simplify the inheritance chain to remove
nsNativeTheme altogether (so that all nsITheme implementations use
mozilla::widget::Theme).
That's not hard to do mechanically, but rather than dumping all of
nsNativeTheme into Theme I'd like to do it a bit more carefully, to hopefully
remove a lot of the helpers that nsNativeTheme has to deal with XUL and so on
and use something nicer. Eventually the inheritance chain will be something
like:
* nsITheme : public nsISupports
* Theme : public nsITheme, public nsITimerCallback, public nsINamed
* ThemeCocoa : public Theme
* nsNativeThemeCocoa : public ThemeCocoa
* nsNativeThemeWin : public Theme
* nsNativeThemeGtk : public Theme
Differential Revision: https://phabricator.services.mozilla.com/D135668
To do this, we always draw the native titlebar behind the toolbox, and
then make the toolbox adapt to it by using the titlebar radius. This
makes us preserve the shadow properly.
On Wayland we'd double-draw the shadow (see bug 1509931 comment 4) so
this fixes it by trimming it as well using border-radius.
Differential Revision: https://phabricator.services.mozilla.com/D128681
See the comments as for why. If as a user you want to get this behavior
you could put something like:
:root { color-scheme: light dark }
in a user stylesheet, but that could cause the same contrast issues the
allow-gtk-dark-theme pref has now.
Differential Revision: https://phabricator.services.mozilla.com/D132361
This prevents contrast issues with colors that are very similar to the
selection background.
See before / after screenshots. Selection on higher-contrasting
foregrounds still looks good.
This is the alpha channel that e.g., Bugzilla uses on dark mode
(so I didn't just mint it).
Differential Revision: https://phabricator.services.mozilla.com/D132022
The previous patch would be a better fix, but it causes some xpcshell
crashes on Linux which I haven't figured out yet (because initializing
LookAndFeel initializes gfxPlatform).
This should be less risky and still fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D132011
This causes (among other things) pages to be dark when using regular
windows system colors and forcing colors to "always", which is nice.
Differential Revision: https://phabricator.services.mozilla.com/D131165
In some platforms (like macOS, windows dark mode, android, and some gtk
themes) the foreground selection color might be `currentcolor`, and that
doesn't generally guarantee enough contrast with the attention
background.
Remove HeadlessLookAndFeelGTK's handling of this color since it's
useless (always overridden by prefs in all.js)
Differential Revision: https://phabricator.services.mozilla.com/D130617
These are only used for frameset painting and the non-e10s <select>
dropdown focus codepath. We have other more appropriate standard
colors for this.
Differential Revision: https://phabricator.services.mozilla.com/D129992
And remove the autofill.background pref for 95 (or 96, depending on
when this lands) assuming nothing terrible causes us to turn it off on
94.
Differential Revision: https://phabricator.services.mozilla.com/D129988
To more properly support Linux having a different default at runtime.
Expose the resolved value in appinfo for convenience, and use it in the
front-end as needed.
Differential Revision: https://phabricator.services.mozilla.com/D129004
We use "is-in-chrome-docshell" rather than "is a chrome doc" so that about:
pages that are loaded in the content area (like about:addons etc) follow the
general content theme as well.
Cache the relevant color schemes since having that many branches on the default
system theme made me a bit uncomfortable, and this code can be called quite a
lot... Though it probably isn't such a huge deal. This makes us initialize the
theme right away, so make sure subclasses do the right thing. This in practice
was only an issue for GTK, which does cache the "system theme is dark" bit.
Differential Revision: https://phabricator.services.mozilla.com/D128674
We always use alpha visual for WebRender, and appearance: none is
unnecessary (root element has no intrinsic appearance).
Differential Revision: https://phabricator.services.mozilla.com/D128682
Remove the follow-firefox-theme pref as now that's default everywhere,
and document better the behavior of the color-scheme property by
reworking and commenting the logic on it a bit.
Differential Revision: https://phabricator.services.mozilla.com/D128610
We know how to paint dark stuff now. Change the tests so that we use a
light color-scheme on chrome documents that we compare against content
documents, and simplify some code now that the non-native theme is
everywhere.
Differential Revision: https://phabricator.services.mozilla.com/D128485
Emilio Cobos Álvarez
Cristian Tuns
Brad Werth
Butkovits Atila
Marian-Vasile Laza
Xidorn Quan
Andi-Bogdan Postelnicu
lamoure6
Jonathan Kew
stransky