2019-03-07 00:34:30 +03:00
|
|
|
/* -*- 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"
|
2020-01-08 04:21:30 +03:00
|
|
|
#include "mozilla/Encoding.h"
|
2020-11-23 19:21:38 +03:00
|
|
|
#include "mozilla/Preferences.h"
|
2019-07-26 04:10:23 +03:00
|
|
|
#include "mozilla/StaticPrefs_browser.h"
|
2019-08-28 16:09:36 +03:00
|
|
|
#include "mozilla/StaticPrefs_devtools.h"
|
2021-09-13 02:37:47 +03:00
|
|
|
#include "mozilla/StaticPrefs_widget.h"
|
2021-08-20 16:03:40 +03:00
|
|
|
#include "mozilla/StaticPrefs_ui.h"
|
2019-04-17 01:32:53 +03:00
|
|
|
#include "mozilla/Telemetry.h"
|
2019-03-07 00:34:30 +03:00
|
|
|
#include "mozilla/LookAndFeel.h"
|
2021-04-02 15:22:14 +03:00
|
|
|
#include "mozilla/ServoBindings.h"
|
2019-03-07 00:34:30 +03:00
|
|
|
#include "mozilla/dom/Document.h"
|
|
|
|
#include "nsContentUtils.h"
|
|
|
|
|
2019-07-11 00:46:21 +03:00
|
|
|
#define AVG2(a, b) (((a) + (b) + 1) >> 1)
|
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
namespace mozilla {
|
|
|
|
|
2019-11-30 14:57:10 +03:00
|
|
|
using dom::Document;
|
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
bool PreferenceSheet::sInitialized;
|
|
|
|
PreferenceSheet::Prefs PreferenceSheet::sContentPrefs;
|
|
|
|
PreferenceSheet::Prefs PreferenceSheet::sChromePrefs;
|
2021-07-25 00:10:44 +03:00
|
|
|
PreferenceSheet::Prefs PreferenceSheet::sPrintPrefs;
|
2019-03-07 00:34:30 +03:00
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
2020-01-08 04:21:30 +03:00
|
|
|
nsAutoCString value;
|
|
|
|
Preferences::GetCString(aPrefName, value);
|
|
|
|
if (value.IsEmpty() || Encoding::UTF8ValidUpTo(value) != value.Length()) {
|
2019-03-07 00:34:30 +03:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
nscolor result;
|
|
|
|
if (!ServoCSSParser::ComputeColor(nullptr, NS_RGB(0, 0, 0), value, &result)) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
aColor = result;
|
|
|
|
}
|
|
|
|
|
2021-07-25 00:10:44 +03:00
|
|
|
auto PreferenceSheet::PrefsKindFor(const Document& aDoc) -> PrefsKind {
|
2019-08-28 16:09:36 +03:00
|
|
|
// 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()) {
|
2021-07-25 00:10:44 +03:00
|
|
|
return PrefsKind::Chrome;
|
2019-08-28 16:09:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (aDoc.IsInChromeDocShell()) {
|
2021-07-25 00:10:44 +03:00
|
|
|
return PrefsKind::Chrome;
|
2019-08-28 16:09:36 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
if (aDoc.IsBeingUsedAsImage() && aDoc.IsDocumentURISchemeChrome()) {
|
2021-07-25 00:10:44 +03:00
|
|
|
return PrefsKind::Chrome;
|
2019-08-28 16:09:36 +03:00
|
|
|
}
|
|
|
|
|
2021-07-25 00:10:44 +03:00
|
|
|
if (aDoc.IsStaticDocument()) {
|
|
|
|
return PrefsKind::Print;
|
|
|
|
}
|
|
|
|
|
|
|
|
return PrefsKind::Content;
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
2019-03-07 00:36:12 +03:00
|
|
|
static bool UseAccessibilityTheme(bool aIsChrome) {
|
2019-03-07 00:34:30 +03:00
|
|
|
return !aIsChrome &&
|
2020-06-11 14:27:43 +03:00
|
|
|
!!LookAndFeel::GetInt(LookAndFeel::IntID::UseAccessibilityTheme, 0);
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
2019-11-15 16:39:08 +03:00
|
|
|
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;
|
2021-09-13 02:37:47 +03:00
|
|
|
|
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);
|
|
|
|
}
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2021-04-02 15:22:14 +03:00
|
|
|
const bool useStandins = nsContentUtils::UseStandinsForNativeColors();
|
2021-07-28 20:25:59 +03:00
|
|
|
// 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 &&
|
2019-03-07 00:34:30 +03:00
|
|
|
!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;
|
2021-11-02 13:45:04 +03:00
|
|
|
|
|
|
|
// 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);
|
|
|
|
|
2021-04-02 15:22:14 +03:00
|
|
|
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);
|
2019-03-07 00:34:30 +03:00
|
|
|
} else {
|
2021-04-02 15:22:14 +03:00
|
|
|
using ColorID = LookAndFeel::ColorID;
|
|
|
|
const auto standins = LookAndFeel::UseStandins(useStandins);
|
2021-11-02 21:08:07 +03:00
|
|
|
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(
|
2021-11-02 21:08:07 +03:00
|
|
|
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);
|
2021-07-28 20:25:58 +03:00
|
|
|
|
|
|
|
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;
|
2021-07-28 20:25:58 +03:00
|
|
|
} 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)));
|
2021-07-28 20:25:58 +03:00
|
|
|
} else {
|
|
|
|
// Otherwise we keep the default visited link color
|
|
|
|
}
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2021-07-28 20:25:59 +03:00
|
|
|
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;
|
2021-07-28 20:25:59 +03:00
|
|
|
}
|
2019-07-11 00:46:21 +03:00
|
|
|
}
|
2019-03-07 00:34:30 +03:00
|
|
|
|
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);
|
|
|
|
}
|
2019-03-07 00:34:30 +03:00
|
|
|
|
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);
|
2019-11-15 16:39:08 +03:00
|
|
|
mUseDocumentColors = UseDocumentColors(aIsChrome, mUseAccessibilityTheme);
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
void PreferenceSheet::Initialize() {
|
|
|
|
MOZ_ASSERT(NS_IsMainThread());
|
|
|
|
MOZ_ASSERT(!sInitialized);
|
|
|
|
|
|
|
|
sInitialized = true;
|
|
|
|
|
|
|
|
sContentPrefs.Load(false);
|
|
|
|
sChromePrefs.Load(true);
|
2021-07-25 00:10:44 +03:00
|
|
|
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;
|
2021-07-25 00:10:44 +03:00
|
|
|
}
|
2019-04-17 01:32:53 +03:00
|
|
|
|
|
|
|
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,
|
2021-03-10 01:31:32 +03:00
|
|
|
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
|
2021-03-10 01:31:32 +03:00
|
|
|
// 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.
|
2021-03-10 01:31:32 +03:00
|
|
|
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);
|
2021-03-10 01:31:32 +03:00
|
|
|
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);
|
2021-03-10 01:31:32 +03:00
|
|
|
}
|
2019-10-04 19:44:49 +03:00
|
|
|
|
|
|
|
Telemetry::ScalarSet(Telemetry::ScalarID::A11Y_BACKPLATE,
|
|
|
|
StaticPrefs::browser_display_permit_backplate());
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
2021-08-20 16:03:40 +03:00
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
} // namespace mozilla
|
2019-07-11 00:46:21 +03:00
|
|
|
|
|
|
|
#undef AVG2
|