This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
This is reasonably straight-forward and should allow us change the
desired behavior on platforms if / when we need.
Also, this adds tests for the feature by using the relevant float pref
(though we can't easily assert the full-zoom behavior because it changes
the size of the reftest window itself).
Differential Revision: https://phabricator.services.mozilla.com/D148902
Now that cbindgen and rust support const generics, it seems more simple.
This centralizes all the relevant font constants etc in rust and avoids
conversions when going from rust to C++ and vice versa.
Differential Revision: https://phabricator.services.mozilla.com/D148847
There's nobody working on it, and tooltips should hopefully be nice
enough after recent changes (bug 1765423).
Having it enabled causes artifacts like bug 1767815 comment 3. We can
always rescue this from hg history if needed.
Differential Revision: https://phabricator.services.mozilla.com/D145621
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
