This is based off work by smurfd. But this patch doesn't support buttons
both at the left and right, which simplifies a lot the implementation.
Also, clean-up the existing env variables while at it.
Co-authored-by: Nicklas Boman <smurfd@gmail.com>
Differential Revision: https://phabricator.services.mozilla.com/D132073
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
This is a regression from bug 1681356. nsWindow::GtkWindowDecoration()
default-initializes a GtkWindowDecoration, which ends up being
GTK_DECORATION_SYSTEM since that's the first variant.
Fix the check by using the proper function
GetSystemGtkWindowDecoration(). Quite a footgun...
Differential Revision: https://phabricator.services.mozilla.com/D129005
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
Emilio Cobos Álvarez
Stephen A Pohl
criss
stransky
Narcis Beleuzu
Andrew Osmond
Bob Owen
Karl Tomlinson
Iulian Moraru
Dorel Luca
Masayuki Nakano