This basically pref-gates some of the accent-color changes that landed before
the soft-freeze to match current release behavior, at least for now.
In the future we might want to reconsider turning these on, but at the very
least we should figure out a good story for the grey-ish accent colors, see the
comments in the pref definitions.
The only tricky bit is the use-theme-accent pref handling. I made it specific
to the non-native-theme again so that AccentColor and NNT kept behaving
consistently, but AccentColor in the browser chrome used the real accent color.
Differential Revision: https://phabricator.services.mozilla.com/D150339
It'd be weird otherwise, as in platforms where use-theme-accent is false
(Windows), form controls would be blue (the default accent color) but
the AccentColor color would be the system accent color still.
Differential Revision: https://phabricator.services.mozilla.com/D149877
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
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
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
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
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
Many users report that GeckoView returns non-coarse value for primary pointer
capabilities. Actually, we assume that primary pointer device is 1st device by
`InputDevice.getDeviceIds`, but some mobile devices seems not to return touch
screen as 1st item according to user reports.
Also, Android's `InputDevice` API doesn't define what is primary pointer
device, so we cannot assume primary pointer device well.
Other implements are,
- Chrome returns coarse if something input device has coarse capability.
- Firefox for Windows seems to return coarse if it is tablet mode.
So we should return coarse as primary pointer capability when having touch
screen, like Chrome.
But there is still another issue.
When I check some devices (including Android VM on Chrome OS), even if no touch
screen, the `InputDevice`'s source may has `SOURCE_TOUCHSCREEN`. Chrome checks
that fine pointer at first, then it checks coarse pointer. But current GV is
coarse pointer at first. Since the `InputDevice`'s source may have both
`SOURCE_MOUSE` and `SOURCE_TOUCHSCREEN` on touchpad/mouse, GV returns different
result. So we shouldn't check `SOURCE_TOUCHSCREEN` at first.
Differential Revision: https://phabricator.services.mozilla.com/D129901
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
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
Eventually we should support all of them, but for now they are only used
by native code (unless you enable the color-scheme pref) and these will
be enough.
Differential Revision: https://phabricator.services.mozilla.com/D126737
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
We only draw a scrollbar thumb, so it's easy enough (fair amount of
boilerplate, though).
For now I've done the trivial thing (keep painting a round thumb without
other fancy things), as that's what we were doing, but in the future we
should consider drawing a stroke around the thumb like cocoa does to add
more contrast.
This patch does change behavior in some cases. For example dark websites
now get a lighter, easier to distinguish scrollbar, thanks to the
scrollbar darkening code in nsNativeBasicTheme.cpp.
Differential Revision: https://phabricator.services.mozilla.com/D125826
This is an oversight. I made selecteditem be -moz-html-cellhighlight,
but that's for inactive cells.
Use the inactive cell color everywhere (though android doesn't
differentiate). This matches other browsers and what was reviewed on
this bug.
MANUAL PUSH: The semi-transparent text-selection-disabled color caused
one test failure CLOSED TREE.
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
I tied it to the use-theme-accent bit in non-native-theme just for
convenience (so that form controls just react to this).
This works nicely, but I didn't turn this on by default because the
accessiblecaret images are hardcoded-blue pngs, and they look ugly
without being the same color as the native accent.
Differential Revision: https://phabricator.services.mozilla.com/D120898
This shouldn't have a meaningful behavior change, as the default link
color right now is taken from the browser.anchor_color pref.
Returning this color from -moz-nativehyperlinktext makes no sense, and
it wasn't being handled correctly before: On GeckoView this color was
transparent.
The other patches in this bug cause NS_SAME_AS_FOREGROUND_COLOR to be
handled correctly, as currentColor, and cause a test failure on android
which asserts that -moz-nativehyperlinktext doesn't return the initial
value.
This color is supposed to be internal, but is has been historically
exposed to the web. Will try to unship these on a follow-up bug.
MANUAL PUSH: Orange fix on a CLOSED TREE
Differential Revision: https://phabricator.services.mozilla.com/D117674
After bug 1697607 and the subsequent pref removal this code only runs in
the parent process.
After bug 1699088 the caller takes care of caching. So there should be
no need to cache stuff ourselves.
Differential Revision: https://phabricator.services.mozilla.com/D110871
There's no reason we can't just query LookAndFeel and we need to use
sSystemMetrics. In the past, LookAndFeel queries were not cached, but
this is no longer the case, so perf wise should be pretty equivalent.
Note that we don't need the NS_SUCCEEDED checks because the default
value from GetInt if the platform doesn't support it is 0 anyways.
Differential Revision: https://phabricator.services.mozilla.com/D110805
After this patch, there are two remaining pieces to fix bug 1700294:
* macOS nsLookAndFeel needs to return the right colors for light / dark
appearance.
* We need to return ColorScheme::Dark for the right documents in
ColorSchemeForDocument.
Both of those should be straight-forward.
Differential Revision: https://phabricator.services.mozilla.com/D110680
Some GTK themes use very soft colors for selection backgrounds, using
darker colors for the text. This makes the tab and focus outlines in the
tab bar not have sufficient contrast with usual backgrounds.
I needed to do this for bug 1690778, but it seems worth doing it on the
front-end as well.
Differential Revision: https://phabricator.services.mozilla.com/D104547
This adds a new LookAndFeel implementation, RemoteLookAndFeel, which can
be used in content processes and is supplied with all of its values by the
parent process.
Co-authored-by: Cameron McCormack <cam@mcc.id.au>
Differential Revision: https://phabricator.services.mozilla.com/D97977
Aside from automating boilerplate, this will allow reusing some of these
structs for full LookAndFeel remoting in bug 1470983.
Differential Revision: https://phabricator.services.mozilla.com/D94531
Content processes will now receive cached values for GetFontImpl() from the
parent process during initialization and whenever the theme changes.
This eliminates the use of several Win32k calls in content.
Differential Revision: https://phabricator.services.mozilla.com/D83406
