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
Apparently ActiveCaption/CaptionText/InactiveCaption/InactiveCaptionText
are supposed to be used for titlebars, so implement them properly and
remove the GTK-specific colors.
Differential Revision: https://phabricator.services.mozilla.com/D128028
Now that windows is going to support dark colors, we want to make it
behave like other platforms in this regard.
Having a single pref for this seems better.
Differential Revision: https://phabricator.services.mozilla.com/D127624
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
This patch does three things:
* Unifies mac and gtk's buttonactivetext system colors (unships mac's from
content, but it was never meant to be exposed).
* Simplifies the forms.css rules, since <input type=color>'s color property
value doesn't affect its rendering in any meaningful way.
* Adds a buttonactiveface color, which we'll use to provide dark backgrounds
for buttons in Windows dark mode (and is good practice, since generally
every text system color should have a corresponding background).
So as-is it shouldn't change content-exposed behavior (except we stop exposing
the -moz-mac-buttonactivetext to content), but it's a worthy cleanup.
Depends on D127246
Differential Revision: https://phabricator.services.mozilla.com/D127259
And make sure the caret ends up being visible, rather than _not_
visible.
This should be implementable on windows as well. It seems macOS doesn't
have a timeout thing.
Differential Revision: https://phabricator.services.mozilla.com/D122132
RestoreSystemTheme() can trigger gtk theme name changes which can
trigger invalidations again. The other theme changes
(WithAltThemeConfigured and MatchFirefoxThemeIfNeeded) already did this
correctly.
Differential Revision: https://phabricator.services.mozilla.com/D120958
I'm not sure what information would be useful in other OSes, so ifdef
the row for GTK for now, but I made this trivial to show in Windows /
macOS / Android as soon as they return useful information.
Differential Revision: https://phabricator.services.mozilla.com/D120331
This theme only styles menus with menu:backdrop (which always seems to
match for context menus).
Try that before giving up. Also, fall back to the window background if
that would ever fail (which seems better than just rendering
transparent).
Differential Revision: https://phabricator.services.mozilla.com/D120199
This doesn't change behavior on GNOME because we already set
"gtk-application-prefer-dark-theme" to dark, and the fallback theme is
Adwaita, but on KDE we get the wrong close icons if we don't do this.
Differential Revision: https://phabricator.services.mozilla.com/D117724
While testing the above patch on a variety of gtk themes, I noticed that
selection colors were inconsistent (as in, from the old theme) when
switching gtk themes, and tracked that down to this call.
Since we only need to restore the theme when actually overridden, track
that instead.
Differential Revision: https://phabricator.services.mozilla.com/D118311
This matches what macOS is doing in bug 1715145, and improves the
situation in the cases the user chooses a light Firefox theme, but a
dark GTK theme, or vice versa.
The nice thing of doing it globally is that we don't need to teach the
GTK code to paint with different color schemes in different windows,
which would be massively annoying.
This is expected to have an slight performance cost on startup for
light-theme users (as we need to read the dark gtk theme colors), but
it's hopefully ok.
Depends on D117227
Differential Revision: https://phabricator.services.mozilla.com/D117228
The right fix for this theme in particular would be for WidgetUsesImage
to check "border-image". However, that doesn't work (instead I get a GTK
warning saying that border-image is not gettable).
So instead, make sure that we fallback to unthemed colors if the thumb
would be invisible in any of its states. This is more resilient anyways.
Depends on D116936
Differential Revision: https://phabricator.services.mozilla.com/D116937
This was an oversight of mine when originally writing this code. We need
to substitute longer prefixes first, otherwise themes like "Foo-Darker"
would end up with a "Foo-er" theme rather than "Foo", and we'd just fall
back to Adwaita (which is not a huge deal, but not the intent of this
code).
Differential Revision: https://phabricator.services.mozilla.com/D116392
`LOG` is defined by `nsWindow.h` for a shortcut of `MOZ_LOG` for generic use
under `widget/gtk`. However, some cpp files do `#undef LOG` and redefine it.
This causes the CPP file order important in unified cpp files since a CPP
file's `LOG` may be redefined unexpectedly with changing the unified order
and/or group. Therefore, each cpp file should define its own macro name
instead of redefining `LOG`.
Differential Revision: https://phabricator.services.mozilla.com/D115978
They more logically belong there, and this should result in less signal
handlers etc as a side effect (not that it matters much anyways).
Differential Revision: https://phabricator.services.mozilla.com/D115037
And since, when present, these are the colors for a selected cell, use
them for HTML cell highlight colors (the <select multiple> ones).
Depends on D114392
Differential Revision: https://phabricator.services.mozilla.com/D114393
As it won't get enough contrast anyways. This is what Gecko does on macOS where
selection colors are also semi-transparent.
Depends on D114391
Differential Revision: https://phabricator.services.mozilla.com/D114392
I wrote these functions, but they only have one caller now so they can
go be back to the switch statement.
Depends on D114389
Differential Revision: https://phabricator.services.mozilla.com/D114390
With the theme in comment 3 context menus in e.g. the DevTools style
inspector were already broken before the regressing patch.
This implements a hacky way to get the central pixel of a pattern image,
or a relevant color from a gradient, and use it as a background-color
instead of transparent.
Differential Revision: https://phabricator.services.mozilla.com/D114428
To flip context menu correctly near the monitor edge we need to use
correct gravity and anchor of 2x2 size for the gdk_window_move_to_rect.
Differential Revision: https://phabricator.services.mozilla.com/D113981
We'll have to pay this startup time penalty eventually for light theme
users as well but, until we do, we can avoid this regression.
Differential Revision: https://phabricator.services.mozilla.com/D114215
And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
We're going to change the setup a bit to support both light and dark
system colors in the chrome process, like mac does. This is just
refactoring though.
Remove some unneeded IsContentProcess() check since it can't happen now
that we always enable RemoteLookAndFeel.
Differential Revision: https://phabricator.services.mozilla.com/D113542
