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
Add initial support for the color-scheme CSS property, allowing pages to
choose between light and dark system colors per-element, and such.
Things that are left to do so that this can be enabled by default:
* Dark system colors on Windows / Android / Standins.
* Dark Canvas/CanvasText/Link visited colors (which right now are set
via PreferenceSheet).
* Dark form controls in nsNativeBasicTheme.
* Processing the color-scheme meta tag to fill-in
Document::mColorSchemeBits.
But this seems like enough progress to be landable on its own.
Differential Revision: https://phabricator.services.mozilla.com/D120843
It probably did something more useful in the past, but right now it's
only used to avoid throttling some overflow-causing animations.
It returns 0 everywhere except on Android (for some reason?), but in any
case it doesn't seem this would need to be a LookAndFeel integer, it
could just be a regular pref that we turn on for tests.
However the tests pass with this patch locally, so for now I'm not
adding a pref to replace it.
Differential Revision: https://phabricator.services.mozilla.com/D120871
Instead, use default colors.
Testing this properly requires writing test infrastructure for paged tests with
"print backgrounds" settings turned off, not sure if worth it.
Depends on D120679
Differential Revision: https://phabricator.services.mozilla.com/D120680
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
Some pages use this to hide the focus outline. On Blink it seems black,
WebKit uses it to expose the OS accent color. Make it black, which is
the default when the color isn't implemented on a given platform.
Differential Revision: https://phabricator.services.mozilla.com/D119036
Some pages use this to hide the focus outline. On Blink it seems black,
WebKit uses it to expose the OS accent color. Make it black, which is
the default when the color isn't implemented on a given platform.
Differential Revision: https://phabricator.services.mozilla.com/D119036
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
This patch also removes the pref widget.system-colors-follow-theme, which was
only true on macOS. System colors now follow the global Firefox theme.
Differential Revision: https://phabricator.services.mozilla.com/D117098
And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
And add code to use the appropriate variant like we do in macOS with
respect-system-appearance (but this still needs more work as noted in
StaticPrefList.yaml).
Still, it cleans up a bunch, and allows to not depend on the content
process boundary to provide light system colors.
Depends on D113542
Differential Revision: https://phabricator.services.mozilla.com/D113543
This will allow detecting the system theme, which allows fixing some of
the blocked bugs.
Note that when using the system theme we will still match light or dark
appropriately, so this shouldn't change behavior just yet.
Differential Revision: https://phabricator.services.mozilla.com/D113516
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486
This adds a new @media query -moz-toolbar-prefers-color-scheme which works like
prefers-color-scheme but is set based on the browser theme rather than the OS
theme. The background colour of the toolbar is used to determine the theme
dark/light preference. This will be used for in-content common.css pages and
other UI elements that include that stylesheet in the browser-chrome through
shadow DOM.
The end result is that about: pages, infobars, and modals will now "match" the
browser theme (just light/dark mode, not LWT theming support).
Differential Revision: https://phabricator.services.mozilla.com/D111486