gecko-dev/layout/style/PreferenceSheet.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

277 строки
9.8 KiB
C++
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#include "PreferenceSheet.h"
#include "ServoCSSParser.h"
#include "MainThreadUtils.h"
#include "mozilla/Encoding.h"
#include "mozilla/Preferences.h"
#include "mozilla/StaticPrefs_browser.h"
#include "mozilla/StaticPrefs_devtools.h"
#include "mozilla/StaticPrefs_widget.h"
#include "mozilla/StaticPrefs_ui.h"
#include "mozilla/Telemetry.h"
#include "mozilla/LookAndFeel.h"
#include "mozilla/ServoBindings.h"
#include "mozilla/dom/Document.h"
#include "nsContentUtils.h"
#define AVG2(a, b) (((a) + (b) + 1) >> 1)
namespace mozilla {
using dom::Document;
bool PreferenceSheet::sInitialized;
PreferenceSheet::Prefs PreferenceSheet::sContentPrefs;
PreferenceSheet::Prefs PreferenceSheet::sChromePrefs;
PreferenceSheet::Prefs PreferenceSheet::sPrintPrefs;
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
static void GetColor(const char* aPrefName, ColorScheme aColorScheme,
nscolor& aColor) {
nsAutoCString darkPrefName;
if (aColorScheme == ColorScheme::Dark) {
darkPrefName.Append(aPrefName);
darkPrefName.AppendLiteral(".dark");
aPrefName = darkPrefName.get();
}
nsAutoCString value;
Preferences::GetCString(aPrefName, value);
if (value.IsEmpty() || Encoding::UTF8ValidUpTo(value) != value.Length()) {
return;
}
nscolor result;
if (!ServoCSSParser::ComputeColor(nullptr, NS_RGB(0, 0, 0), value, &result)) {
return;
}
aColor = result;
}
auto PreferenceSheet::PrefsKindFor(const Document& aDoc) -> PrefsKind {
// DevTools documents run in a content frame but should temporarily use
// chrome preferences, in particular to avoid applying High Contrast mode
// colors. See Bug 1575766.
if (aDoc.IsDevToolsDocument() &&
StaticPrefs::devtools_toolbox_force_chrome_prefs()) {
return PrefsKind::Chrome;
}
if (aDoc.IsInChromeDocShell()) {
return PrefsKind::Chrome;
}
if (aDoc.IsBeingUsedAsImage() && aDoc.IsDocumentURISchemeChrome()) {
return PrefsKind::Chrome;
}
if (aDoc.IsStaticDocument()) {
return PrefsKind::Print;
}
return PrefsKind::Content;
}
static bool UseAccessibilityTheme(bool aIsChrome) {
return !aIsChrome &&
!!LookAndFeel::GetInt(LookAndFeel::IntID::UseAccessibilityTheme, 0);
}
static bool UseDocumentColors(bool aIsChrome, bool aUseAcccessibilityTheme) {
switch (StaticPrefs::browser_display_document_color_use()) {
case 1:
return true;
case 2:
return aIsChrome;
default:
return !aUseAcccessibilityTheme;
}
}
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
void PreferenceSheet::Prefs::LoadColors(bool aIsLight) {
auto& colors = aIsLight ? mLightColors : mDarkColors;
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
if (!aIsLight) {
// Initialize the dark-color-scheme foreground/background colors as being
// the reverse of these members' default values, for ~reasonable fallback if
// the user configures broken pref values.
std::swap(colors.mDefault, colors.mDefaultBackground);
}
const bool useStandins = nsContentUtils::UseStandinsForNativeColors();
// Users should be able to choose to use system colors or preferred colors
// when HCM is disabled, and in both OS-level HCM and FF-level HCM.
// To make this possible, we don't consider UseDocumentColors and
// mUseAccessibilityTheme when computing the following bool.
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
const bool usePrefColors = !useStandins && !mIsChrome &&
!StaticPrefs::browser_display_use_system_colors();
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
const auto scheme = aIsLight ? ColorScheme::Light : ColorScheme::Dark;
// Link colors might be provided by the OS, but they might not be. If they are
// not, then fall back to the pref colors.
//
// In particular, we don't query active link color to the OS.
GetColor("browser.anchor_color", scheme, colors.mLink);
GetColor("browser.active_color", scheme, colors.mActiveLink);
GetColor("browser.visited_color", scheme, colors.mVisitedLink);
if (usePrefColors) {
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
GetColor("browser.display.background_color", scheme,
colors.mDefaultBackground);
GetColor("browser.display.foreground_color", scheme, colors.mDefault);
} else {
using ColorID = LookAndFeel::ColorID;
const auto standins = LookAndFeel::UseStandins(useStandins);
colors.mDefault = LookAndFeel::Color(ColorID::Windowtext, scheme, standins,
colors.mDefault);
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
colors.mDefaultBackground = LookAndFeel::Color(
ColorID::Window, scheme, standins, colors.mDefaultBackground);
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
colors.mLink = LookAndFeel::Color(ColorID::MozNativehyperlinktext, scheme,
standins, colors.mLink);
if (auto color = LookAndFeel::GetColor(
ColorID::MozNativevisitedhyperlinktext, scheme, standins)) {
// If the system provides a visited link color, we should use it.
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
colors.mVisitedLink = *color;
} else if (mUseAccessibilityTheme) {
// The fallback visited link color on HCM (if the system doesn't provide
// one) is produced by preserving the foreground's green and averaging the
// foreground and background for the red and blue. This is how IE and
// Edge do it too.
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
colors.mVisitedLink = NS_RGB(
AVG2(NS_GET_R(colors.mDefault), NS_GET_R(colors.mDefaultBackground)),
NS_GET_G(colors.mDefault),
AVG2(NS_GET_B(colors.mDefault), NS_GET_B(colors.mDefaultBackground)));
} else {
// Otherwise we keep the default visited link color
}
if (mUseAccessibilityTheme) {
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
colors.mActiveLink = colors.mLink;
}
}
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
{
// These two are not color-scheme dependent, as we don't rebuild the
// preference sheet based on effective color scheme.
GetColor("browser.display.focus_text_color", ColorScheme::Light,
colors.mFocusText);
GetColor("browser.display.focus_background_color", ColorScheme::Light,
colors.mFocusBackground);
}
// Wherever we got the default background color from, ensure it is opaque.
colors.mDefaultBackground =
NS_ComposeColors(NS_RGB(0xFF, 0xFF, 0xFF), colors.mDefaultBackground);
}
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
bool PreferenceSheet::Prefs::NonNativeThemeShouldBeHighContrast() const {
// We only do that if we are overriding the document colors. Otherwise it
// causes issues when pages only override some of the system colors,
// specially in dark themes mode.
return StaticPrefs::widget_non_native_theme_always_high_contrast() ||
!mUseDocumentColors;
}
void PreferenceSheet::Prefs::Load(bool aIsChrome) {
*this = {};
mIsChrome = aIsChrome;
mUseAccessibilityTheme = UseAccessibilityTheme(aIsChrome);
LoadColors(true);
LoadColors(false);
mUseDocumentColors = UseDocumentColors(aIsChrome, mUseAccessibilityTheme);
}
void PreferenceSheet::Initialize() {
MOZ_ASSERT(NS_IsMainThread());
MOZ_ASSERT(!sInitialized);
sInitialized = true;
sContentPrefs.Load(false);
sChromePrefs.Load(true);
sPrintPrefs = sContentPrefs;
if (!sPrintPrefs.mUseDocumentColors) {
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
// For printing, we always use a preferred-light color scheme.
//
// When overriding document colors, we ignore the `color-scheme` property,
// but we still don't want to use the system colors (which might be dark,
// despite having made it into mLightColors), because it both wastes ink and
// it might interact poorly with the color adjustments we do while printing.
//
// So we override the light colors with our hardcoded default colors.
sPrintPrefs.mLightColors = Prefs().mLightColors;
}
nsAutoString useDocumentColorPref;
switch (StaticPrefs::browser_display_document_color_use()) {
case 1:
useDocumentColorPref.AssignLiteral("always");
break;
case 2:
useDocumentColorPref.AssignLiteral("never");
break;
default:
useDocumentColorPref.AssignLiteral("default");
break;
}
Telemetry::ScalarSet(Telemetry::ScalarID::A11Y_THEME, useDocumentColorPref,
sContentPrefs.mUseAccessibilityTheme);
if (!sContentPrefs.mUseDocumentColors) {
// If a user has chosen to override doc colors through OS HCM or our HCM,
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
// we should log the user's current foreground (text) color and background
// color. Note, the document color use pref is the inverse of the HCM
// dropdown option in preferences.
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
//
// Note that we only look at light colors because that's the color set we
// use when forcing colors (since color-scheme is ignored when colors are
// forced).
//
// The light color set is the one that potentially contains the Windows HCM
// theme color/background (if we're using system colors and the user is
// using a High Contrast theme), and also the colors that as of today we
// allow setting in about:preferences.
Telemetry::ScalarSet(Telemetry::ScalarID::A11Y_HCM_FOREGROUND,
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
sContentPrefs.mLightColors.mDefault);
Telemetry::ScalarSet(Telemetry::ScalarID::A11Y_HCM_BACKGROUND,
Bug 1525107 - Make Canvas/CanvasText and Link colors color-scheme-aware. r=dholbert For that, add `.dark` version of the browser.display* prefs that control the light version of these colors. The default for background/foreground colors are taken from the GenericDarkColors used in LookAndFeel. The defaults for links are based on this discussion: https://github.com/whatwg/html/issues/5426#issuecomment-904021675 (So they effectively match Chrome). Whether the dark colors should be exposed in about:preferences (like the light colors are) is TBD. With this patch, we pass all the tests in: /html/semantics/document-metadata/the-meta-element/color-scheme/ Use the colors to paint the default canvas background and the default colors. There are three "regressions", though they are really progressions: we now render the reference as the test expects (before we rendered a light canvas background even for the reference). Apart of these iframe tests (which we should look into, I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1738380), there are three remaining test failures. Two of them are due to `color: initial` not changing based on the color-scheme. Safari also fails these tests, and the thing they're really testing is whether system colors are preserved at computed-value time: https://github.com/w3c/csswg-drafts/issues/3847 Regarding that change, I'm not so sure the trade-offs there are worth it, as that not only complicates interpolation (we wouldn't be able to use system colors in color-mix among others, see https://github.com/w3c/csswg-drafts/issues/5780) plus it changes inheritance behavior in sorta unexpected ways, see: https://github.com/w3c/csswg-drafts/issues/6773 Which I just filed because apparently no browser implements this correctly. So for now will punt on those (keep matching Safari). There's an svg-as-image test: https://searchfox.org/mozilla-central/rev/f8576fec48d866c5f988baaf1fa8d2f8cce2a82f/testing/web-platform/tests/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html Which isn't using the feature at all and I'm not sure why is it supposed to pass (why prefers-color-scheme: dark is supposed to match that SVG image). This test fails in all browsers apparently: https://wpt.fyi/results/css/css-color-adjust/rendering/dark-color-scheme/svg-as-image.html?label=master&label=experimental&aligned I sent https://github.com/web-platform-tests/wpt/pull/31407 to remove it and hopefully get it reviewed by some Chromium folks. Differential Revision: https://phabricator.services.mozilla.com/D129746
2021-10-29 22:58:25 +03:00
sContentPrefs.mLightColors.mDefaultBackground);
}
Telemetry::ScalarSet(Telemetry::ScalarID::A11Y_BACKPLATE,
StaticPrefs::browser_display_permit_backplate());
}
bool PreferenceSheet::AffectedByPref(const nsACString& aPref) {
const char* prefNames[] = {
StaticPrefs::GetPrefName_devtools_toolbox_force_chrome_prefs(),
StaticPrefs::GetPrefName_privacy_resistFingerprinting(),
StaticPrefs::GetPrefName_ui_use_standins_for_native_colors(),
"browser.anchor_color",
"browser.active_color",
"browser.visited_color",
};
if (StringBeginsWith(aPref, "browser.display."_ns)) {
return true;
}
for (const char* pref : prefNames) {
if (aPref.Equals(pref)) {
return true;
}
}
return false;
}
} // namespace mozilla
#undef AVG2