When running tests on taskcluster, Android emulator often notifes that
virtio (Stylus) driver reports device changed. we have to update
`nsLookAndFeel` that is expensive.
So we should cache pointer capabilities and only update it when it is
changed.
Differential Revision: https://phabricator.services.mozilla.com/D268339
Gtk4 doesn't use different background colors for GtkColumnView (the
replacement for the treeview), so avoid computing one.
Our computation didn't have any guarantee of matching the fieldtext
foreground color.
This matches windows too. Remove unused -moz-eventreerow while at it.
Differential Revision: https://phabricator.services.mozilla.com/D249237
This reverts commit 8f772fe1b2.
Revert "Bug 1962978 - Use non-native listboxes on GTK. r=stransky,geckoview-reviewers,nika"
This reverts commit 751e7a3b2a.
Gtk4 doesn't use different background colors for GtkColumnView (the
replacement for the treeview), so avoid computing one.
Our computation didn't have any guarantee of matching the fieldtext
foreground color.
This matches windows too. Remove unused -moz-eventreerow while at it.
Differential Revision: https://phabricator.services.mozilla.com/D249237
For now this is Windows/Android only right now as we don't have the same set of detection used for IntID::AllPointerCapabilities on other platforms. That work can be done separately by e.g. bug 1874292.
Differential Revision: https://phabricator.services.mozilla.com/D216455
Make the "is hidden due to non-collapsed selection" use the regular
caret-hiding mechanism, so that we make sure nsCaret and paint are
consistent on their caret visibility.
As part of this simplification:
* Remove LookAndFeel::IntID::ShowCaretDuringSelection, it's 0 on all
platforms.
* Remove nsCaret::IsMenuPopupHidingCaret. Is really broken as per the
comments (it assumes single-process mode, doesn't deal with shadow
dom, and it's not like it's particularly useful anyways since the
menu popup could be semi-transparent or what not).
Differential Revision: https://phabricator.services.mozilla.com/D205557
This patch adds support for the Android high contrast text setting. This triggers the prefers-contrast media query as well as prefers-reduced-transparency.
Differential Revision: https://phabricator.services.mozilla.com/D186389
-moz-menubarhovertext has one usage that can go away once we remove
windows 7 / 8 so not touching that yet.
Depends on D182896
Differential Revision: https://phabricator.services.mozilla.com/D182897
That's how we do it for all other platforms. Do this rather than via a
custom mostly-untested pref, which allows us to simplify text zoom
handling.
Differential Revision: https://phabricator.services.mozilla.com/D177062
Implemented the inverted-colors media feature from Media Queries Level 5
for all platforms.
Spec: https://drafts.csswg.org/mediaqueries-5/#inverted
Platform specific implementations:
- Windows: Checks system color filter setting, and if it is inverted
(note: Windows does not live update due to having to read a reg key)
- Mac: Checks dedicated inverted accessibility system setting
- Android: Checks dedicated inverted system setting
- Linux: No GTK API exposes anything like it so always none
Locked behind new pref `layout.css.inverted-colors.enabled`,
always off by default for now.
Also added new WPT tests (none previously).
Other browsers:
- WebKit: shipped since Safari 9.1 (Jan 2017)
- Blink: no signal
Test page: https://goose.icu/inverted-colors
Differential Revision: https://phabricator.services.mozilla.com/D173201
Implemented the prefers-reduced-transparency media query for all
platforms.
Windows and Mac have specific settings which are used, others (Android
and Linux/GTK) have it enabled if prefers-reduced-motion is also enabled
as there is no dedicated setting to check.
Locked behind new pref `layout.css.prefers-reduced-transparency.enabled`,
off by default always for now.
Also added new WPT tests (none previously).
Demo video: https://goose.icu/firefox_prt.mp4
Test page: https://goose.icu/prefers-reduced-transparency
Differential Revision: https://phabricator.services.mozilla.com/D172424
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
Sylvestre Ledru