This revision modifies the Windows definitions of Field, Fieldtext, and
MozDisabledField for high contrast mode. Scoping this more directly
to high contrast mode avoids undesirable knock-on effects in other schemes. In
particular, we want to keep Field mapping to field-like colors, rather than
button colors. This fixes the color of autofill richlistbox. This revision also
fixes the HCM color of disabled checkboxes and radio buttons, which weren't
discernible.
Differential Revision: https://phabricator.services.mozilla.com/D215176
This revision updates the HCM colors of many controls. In particular:
- HCM hover and active states for checkboxes, radio buttons are now discernible
- HCM focus ring colors fixed
- Field, Disabledfield on Windows adjusted to COLOR_BTNFACE
- FieldText on Windows adjusted to COLOR_BTNTEXT to match
- checkbox, radio button colors fixed to more closely match design
Differential Revision: https://phabricator.services.mozilla.com/D213674
This was needed because we didn't use to override the color of the
textfield, so it needed to work with whatever color was there already.
Now that we enforce the color however, there's no point on it being
semi-transparent.
Add a darker version of the color so that it also works on dark mode
(<input style="color-scheme: dark"> or so).
Now that it's opaque, there's no need for Theme.cpp to blend with the
field background.
Differential Revision: https://phabricator.services.mozilla.com/D209021
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
I think we should start off with this. Other platforms can implement
this too, but exposing this to content seems like quite the rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D203405
I think we should start off with this. Other platforms can implement
this too, but exposing this to content seems like quite the rabbit hole.
Differential Revision: https://phabricator.services.mozilla.com/D203405
This avoids big restyles when users have a massive number of tabs. A
color change inherits, so we need to propagate the color change to the
whole subtree, which with a lot of tabs can be huge (66k elements in the
profile in the bug).
Instead, don't change the text color on inactive windows, and fade the
titlebar entirely using opacity, which is a one-element change.
Differential Revision: https://phabricator.services.mozilla.com/D196543
This fixes various things, like sort arrows not working, even in regular
non-mixed-color-scheme settings, and is a lot less code.
The toolbarbutton appearance on the problematic case described in
comment 0 could get some work (the extra borders aren't exactly pretty),
but it's still a much better improvement.
Differential Revision: https://phabricator.services.mozilla.com/D195345
We might want to do this more generally at the PreferencesSheet level
all the times we're forcing colors, but this should be uncontroversial
and fix the default behavior.
Differential Revision: https://phabricator.services.mozilla.com/D192574
This is more like what other browsers do, and makes more sense, it
actually blends the text-color with that opacity, which is what the
front-end uses.
Differential Revision: https://phabricator.services.mozilla.com/D190955
Right now we were relying on the OS colors
(-moz-dialog/-moz-dialogtext/ActiveCaption/CaptionText).
The titlebar ones did the right thing but -moz-dialog and co didn't.
This caused two issues:
* With the titlebar checkbox on, we'd use the system colors even
without prefers-contrast. This is specially noticeable on macOS.
* With prefers-contrast. We used -moz-dialog for the background and the
toolbar on macOS. This caused little contrast.
Support the -moz-headerbar colors in all desktop platforms, and use
those on Linux + HCM, and use browser-custom-colors on Windows / macOS
to override the toolbox background explicitly to fix it.
This setup is a little bit more consistent with all other colors.
Differential Revision: https://phabricator.services.mozilla.com/D190200
I'm about to use them more in the front-end, and it'd be nice if these
did the right thing.
For that, make our stand-ins system return the Firefox titlebar colors.
Put the Windows "show accent color on title bars" code behind a pref
because we don't support it. I filed bug 1851155 to consider enabling it
by default.
After this changes there's only one place to tweak the (cross-platform)
titlebar colors (in nsXPLookAndFeel), with high-contrast mode and so on
behaving correctly by default.
The macOS special-case for the titlebar is to preserve the current
behavior from bug 1711261. If we want to change that to also apply to
dark mode or what not, we can do it in a follow-up.
I didn't bother putting the new colors in test_bug232227. That only
(tries to) test that we return fixed colors when the rfp/stand-ins prefs
are on. But we don't need to test the exact value of all the colors.
Differential Revision: https://phabricator.services.mozilla.com/D187278
This only hides the cursor if it's on the page you're editing, but given
that the point of the feature is to move the cursor out of the way, that
seems acceptable (and honestly it feels more of a feature than a bug).
This should work across platforms (though non-windows platforms need
ui.hideCursorWhileTyping=1 in about:config to enable).
Differential Revision: https://phabricator.services.mozilla.com/D171155
This doesn't change behavior yet because the front-end doesn't use them for the
cases where we're changing behavior, but this is in preparation to use them
unconditionally in the front-end and simplify a bit the code there.
Since we need generic colors, and the default theme light colors are not
particularly useful (they are windows-xp-like titlebar colors), I think this
makes sense.
Differential Revision: https://phabricator.services.mozilla.com/D184707
Some basic clean-up. I want to do this before doing bigger changes in
bug 1843044.
There's tons more code that can get cleaned-up on the widget side, but
let's start with this.
Differential Revision: https://phabricator.services.mozilla.com/D183622
Since the DWM accent colors can be different from the UWP accent colors
(see comments in the bug), expose them as the proper ActiveBorder /
InactiveBorder / ActiveCaption / CaptionText / InactiveCaption /
InactiveCaptionText colors, which have that purpose.
Fix browser-aero.css to use the right color for the border
(ActiveBorder).
Differential Revision: https://phabricator.services.mozilla.com/D183165
-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
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
Other browsers don't do this, and it might confuse users, see e.g., [1]
and bug 1813684.
Before Firefox 110, we didn't do it consistently, but I fixed that in
bug 1807687. See comments in the patch for context, [2] in particular:
> The code being removed here is intended to implement the Windows
> setting 'Underline access keys' in the Keyboard Accessibility
> control panel, which somewhat confusingly also controls whether
> focus rings appear by default when clicking on controls. The former
> part -- the showing and hiding of the underlines based on the
> setting -- was never yet implemented, this is bug 25894. The focus
> rings part was implemented.
Given:
* This setting is confusing.
* Modern windows apps and other browsers don't follow it.
* We already provide other means of achieving the same behavior
(browser.display.show_focus_rings=true).
It seems better to remove. I asked Neil in bug 1813684 in case he felt
more strongly about this, and didn't hear back.
[1]: https://www.reddit.com/r/firefox/comments/116n3kp/why_is_firefox_110_now_putting_a_blue_box_around/
[2]: https://phabricator.services.mozilla.com/D165578#5448547
Differential Revision: https://phabricator.services.mozilla.com/D170395
When we get to NativeGetColor with ColorScheme::Dark and some of the
menu colors, we end up in a somewhat weird state, where most of the
colors come from GenericDarkColor, but some of the colors would use the
IsHighlightColor/IsHighlightTextColor code-path.
Use the non-native menu colors with the dark color-scheme consistently,
to guarantee we get matching color pairs. Note that for native menus
(i.e., Win7/Win8, we can't get here because of [1]).
The behavior when the user selects a light theme is a bit inconsistent
with this (because we'd still use the HCM colors in that case), but
that's both pre-existing and probably not a big deal.
To fix that properly we'd need to either introduce a third
`color-scheme`, which doesn't seem too appealing, or do something like
`color-scheme: light !important` on menus as well with `not
(-moz-windows-default-theme)` (which is fine but not sure it's desired).
[1]: https://searchfox.org/mozilla-central/rev/5ccb73c0217d1710b10d6e6e297cf3396d10ec23/toolkit/themes/windows/global/popup.css#32
Differential Revision: https://phabricator.services.mozilla.com/D169803
This removes the capability of having differently-sized vertical and
horizontal scrollbars (which is only potentially used in windows, and in
practice almost-never used). For that case, we choose the larger of
vertical/horizontal scrollbar sizes.
This is in order to be able to realistically expose the scrollbar size
to CSS, see blocked bug.
We make RecomputeScrollbarParams the central place where each scrollbar
style decides its sizes, and make GetDPIRatioForScrollbarPart handle the
cocoa special-case of scaling to 1 or 2, but nothing else.
Differential Revision: https://phabricator.services.mozilla.com/D168080
I thought of adding that border-y thing, but no other native menus have
them on Win11 at least (tried Explorer and Settings).
It should be doable tho, lmk if you insist.
Differential Revision: https://phabricator.services.mozilla.com/D163172
And hide internal but used values. System fonts are not exposed in the
computed style so this should be fine.
If we need the old values for some obscure reason, it's trivial to alias
them to e.g., menu or so.
Differential Revision: https://phabricator.services.mozilla.com/D163269
Tim Huang
Tamas Szentpeteri
Norisz Fay
Nathan LaPre
Jan-Niklas Jaeschke
Emilio Cobos Álvarez
Cristian Tuns
Masatoshi Kimura
Natalia Csoregi
CanadaHonk
Ben Freist
Sandor Molnar