Maybe we should tweak the wording of the settings checkbox to more
strongly not implying that having it un-checked will not go through
links, but I'm not sure what wording could be best there.
Differential Revision: https://phabricator.services.mozilla.com/D209535
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
Stop supporting following the system preference, but keep macOS users
able to switch to just text controls (accessibility.tabfocus=1) in the
settings.
Change the meaning of the "Use the tab key to move focus between form
controls and links" checkbox in the Firefox settings, which was
introduced in bug 1628476 to override the system setting.
The intention, I think was that this checkbox being off resulted in
"follow the system" behavior, but that didn't quite happen due to a bug
in the preferences code (this[1] won't unset the pref, because of
this[2], which means we'll just return 0).
This patch changes it so that the checkbox instead always ignores the
system setting. There will no longer be a Firefox setting (neither in
the UI nor on about:config) that means "follow system setting".
This allows us to somewhat simplify the approach compared to the
previous patch in D196110, and keep the accessibility.tabfocus working
as the source of truth without a migration.
In the future, we can think of migrating accessibility.tabfocus to a
boolean pref, which would allow us to do the cleanups to the preferences
code that D196110 did.
[1]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/browser/components/preferences/main.js#2252
[2]: https://searchfox.org/mozilla-central/rev/f1532761de0b60337e42c6c3f525288a523dabef/toolkit/content/preferencesBindings.js#450,483
Differential Revision: https://phabricator.services.mozilla.com/D208602
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
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
This is simpler given we only have a couple of windows with these looks,
and removes the dual mode of the ToolbarWindow class.
We just draw the title into the window frame and rely on CSS reserving
enough space (exposed as a new -moz-mac-titlebar-height environment
variable).
We remove the toolbox and toolbar appearance values on mac, now that
they do nothing (toolbar did, but it didn't support dark mode and is
effectively unused).
Differential Revision: https://phabricator.services.mozilla.com/D205469
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 makes all platforms report video-dynamic-range:high if the screen
most closely associated with the document (according to the logic of
nsDeviceContext::FindScreen) is HDR capable.
This removes the LookAndFeel id for VideoDynamicRange, since it is only
used by Gecko_MediaFeatures_VideoDynamicRange, which is being modified
here to use the nsDeviceContext instead.
It also removes gfxPlatform::supportsHDR and its implementations, as it
is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D203329
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 makes all platforms report video-dynamic-range:high if the screen
most closely associated with the document (according to the logic of
nsDeviceContext::FindScreen) is HDR capable.
This removes the LookAndFeel id for VideoDynamicRange, since it is only
used by Gecko_MediaFeatures_VideoDynamicRange, which is being modified
here to use the nsDeviceContext instead.
It also removes gfxPlatform::supportsHDR and its implementations, as it
is no longer used.
Differential Revision: https://phabricator.services.mozilla.com/D203329
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
In order to do it, expose the button padding to CSS via env(), and make
the buttons just use the regular drawing.
This slightly changes the padding to the end of the titlebar to match
one half of the inter-button spacing, rather that however much padding
the headerbar has.
We could improve on this slightly by also exposing the headerbar padding
and applying that to the last button, but that's not terribly easy to do
due to us supporting re-ordering of the titlebar buttons, and reversing
their placement, so it'd involve some rather hacky CSS. Not impossible,
but not trivial, and this looks good enough IMO.
Differential Revision: https://phabricator.services.mozilla.com/D202616
A few stand-in colors were missing dark variants, causing unexpected light elements such as non-native theme tooltips on Linux.
Differential Revision: https://phabricator.services.mozilla.com/D200598
Get titlebar actions from gtk-titlebar-double-click / gtk-titlebar-middle-click gsettings keys and monitor key changes and export it as nsLookAndFeel::GetTitlebarAction().
Differential Revision: https://phabricator.services.mozilla.com/D199882
Map `ActiveCaption` to `Canvas`, `CaptionText` and `InfoText` to the `CanvasText` to conform with [css-color-4 Appendix A: Deprecated CSS System Colors](https://www.w3.org/TR/css-color-4/#deprecated-system-colors) and update expected WPT and dom/canvas test results.
We also need to update the WPT test `testing/web-platform/tests/css/css-color/deprecated-sameas-002.html` to expect `Canvas` system color as well.
Differential Revision: https://phabricator.services.mozilla.com/D198116
Windows is the only platform which doesn't have proper native system
colors, and we have to emulate them. Preserve behavior by returning the
same that field/fieldtext etc used to return.
Differential Revision: https://phabricator.services.mozilla.com/D196596
Override Adwaita / Yaru colors with colors from the libadwaita
documentation.
Do a couple minor tweaks to the urlbar too to match both our default
themes in other platforms and Adwaita.
Differential Revision: https://phabricator.services.mozilla.com/D196153
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
In bug 1861954 I also removed the vibrancy of the places window.
Unlike the browser sidebar this one didn't have an explicit background
color. Add back a system color for the mac sidebar and use it in both
places. This matches the old -moz-mac-source-list color.
Differential Revision: https://phabricator.services.mozilla.com/D195294
This requires moving some code around to PreferenceSheet, but that makes
stuff actually a bit simpler.
Depends on D192574
Differential Revision: https://phabricator.services.mozilla.com/D192575
This changes -moz-bool-pref from @supports to @media, bringing various
improvements:
* @media (-moz-bool-pref) properly reacts to dynamic changes.
* We no longer need to parse chrome:// stylesheets in the main thread
(-moz-bool-pref was the only thing that forced us to do that).
This makes privileged and non-privileged stylesheets more similar.
Differential Revision: https://phabricator.services.mozilla.com/D191196
Use the same system colors there rather than bespoke ones. That allows
us to simplify the CSS, remove macOS-specific system colors, and also
fix this bug.
Differential Revision: https://phabricator.services.mozilla.com/D190460
