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
All NativeGetFont implementations do, so child processes see something
different from parent processes which is pretty unfortunate, and isn't
the goal of RemoteLookAndFeel.
I found this by code inspection. Seems this is mostly used for debugging
etc?
Differential Revision: https://phabricator.services.mozilla.com/D110914
The first part fixes the bookmarks sidebars etc when in a light theme.
The second fixes too-light selection colors in websites.
Differential Revision: https://phabricator.services.mozilla.com/D110729
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
We also cache everywhere whether getting the int/float/color failed, for
example, and do the pref lookup on demand. Seems a bit nicer. We could insert
the pref values on the cache directly on Refresh(), that's another alternative,
but I don't think it matters much either way.
Differential Revision: https://phabricator.services.mozilla.com/D110675
No reason that code needs to be there. The findbar modal highlight stuff is not
being worked on and it was unclear to me why it needed a fission check, so I
removed that special case. The findbar code can customize the colors with
Selection.setColors anyways, which is a better fix.
Depends on D110673
Differential Revision: https://phabricator.services.mozilla.com/D110674
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
This shouldn't change behavior, but is the biggest cross-platform part
of the change so I'd like to get it landed sooner rather than later.
The two calls like:
GetColor(ColorID::TextSelectBackground, color);
if (color == 0x000000) {
mColorTextSelectForeground = NS_RGB(0xff, 0xff, 0xff);
} else {
mColorTextSelectForeground = NS_DONT_CHANGE_COLOR;
}
that I'm removing are just broken. They were calling the version of
GetColor the function that took a default value when the color wasn't
available, not the version of the color with the outparam.
To prevent such mistakes, add two signatures, GetColor(), returning a
Maybe<nscolor> and Color(), returning a color with a fallback.
Differential Revision: https://phabricator.services.mozilla.com/D110651
And make FontID's indexing setup more similar to FloatID / IntID / ColorID. The
values no longer need to match the style constants since Stylo. We could also
cache whether the lookup succeeded for floats / ints, but it might not be worth
it, your call though.
Differential Revision: https://phabricator.services.mozilla.com/D108765
Starting with macOS 10.14, the generic light/dark vibrancy is deprecated, and semantic vibrancy names are preferred.
If we ever need more vibrancy, we can add new values with semantic names.
Depends on D107910
Differential Revision: https://phabricator.services.mozilla.com/D108152
And remove the windows-specific versions of this color.
Also fix the hard-coded defaults by the colors I get in the default windows
theme.
Differential Revision: https://phabricator.services.mozilla.com/D108325
