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/. */
|
|
|
|
|
|
|
|
/* Some prefable colors for style system use */
|
|
|
|
|
|
|
|
#ifndef mozilla_ColorPreferences_h
|
|
|
|
#define mozilla_ColorPreferences_h
|
|
|
|
|
|
|
|
#include "nsColor.h"
|
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
|
|
|
#include "mozilla/ColorScheme.h"
|
2019-03-07 00:34:30 +03:00
|
|
|
|
|
|
|
namespace mozilla {
|
|
|
|
|
|
|
|
namespace dom {
|
|
|
|
class Document;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct PreferenceSheet {
|
|
|
|
struct Prefs {
|
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
|
|
|
struct Colors {
|
2021-07-25 00:10:44 +03:00
|
|
|
nscolor mLink = NS_RGB(0x00, 0x00, 0xEE);
|
|
|
|
nscolor mActiveLink = NS_RGB(0xEE, 0x00, 0x00);
|
|
|
|
nscolor mVisitedLink = NS_RGB(0x55, 0x1A, 0x8B);
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2021-07-25 00:10:44 +03:00
|
|
|
nscolor mDefault = NS_RGB(0, 0, 0);
|
|
|
|
nscolor mDefaultBackground = NS_RGB(0xFF, 0xFF, 0xFF);
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2021-07-25 00:10:44 +03:00
|
|
|
nscolor mFocusText = mDefault;
|
|
|
|
nscolor mFocusBackground = 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
|
|
|
} mLightColors, mDarkColors;
|
|
|
|
|
|
|
|
const Colors& ColorsFor(ColorScheme aScheme) const {
|
2022-04-01 04:21:22 +03:00
|
|
|
return mMustUseLightColorSet || aScheme == ColorScheme::Light
|
|
|
|
? 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
|
|
|
}
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2019-03-07 00:36:12 +03:00
|
|
|
bool mIsChrome = false;
|
|
|
|
bool mUseAccessibilityTheme = false;
|
2019-11-15 16:39:08 +03:00
|
|
|
bool mUseDocumentColors = true;
|
2022-04-01 04:21:22 +03:00
|
|
|
bool mUsePrefColors = false;
|
|
|
|
bool mUseStandins = false;
|
|
|
|
bool mMustUseLightColorSet = false;
|
|
|
|
|
|
|
|
// Sometimes we can force a color scheme on a document, or honor the
|
|
|
|
// preferred color-scheme in more cases, depending on whether we're forcing
|
|
|
|
// colors or not.
|
|
|
|
enum class ColorSchemeChoice : uint8_t {
|
|
|
|
// We're not forcing colors, use standard algorithm based on specified
|
|
|
|
// style and meta tags and so on.
|
|
|
|
Standard,
|
|
|
|
// We can honor whatever the preferred color-scheme for the document is
|
|
|
|
// (the preferred color-scheme of the user, since we're forcing colors).
|
|
|
|
UserPreferred,
|
|
|
|
Light,
|
|
|
|
Dark,
|
|
|
|
};
|
|
|
|
|
|
|
|
ColorSchemeChoice mColorSchemeChoice = ColorSchemeChoice::Standard;
|
2019-03-07 00:34:30 +03:00
|
|
|
|
2021-10-05 17:40:52 +03:00
|
|
|
// Whether the non-native theme should use real system colors for widgets.
|
|
|
|
bool NonNativeThemeShouldBeHighContrast() const;
|
2021-03-16 19:46:05 +03:00
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
void Load(bool aIsChrome);
|
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 LoadColors(bool aIsLight);
|
2019-03-07 00:34:30 +03:00
|
|
|
};
|
|
|
|
|
|
|
|
static void EnsureInitialized() {
|
|
|
|
if (sInitialized) {
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
Initialize();
|
|
|
|
}
|
|
|
|
|
|
|
|
static void Refresh() {
|
|
|
|
sInitialized = false;
|
2021-08-20 16:03:40 +03:00
|
|
|
Initialize();
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
2021-08-20 16:03:40 +03:00
|
|
|
static bool AffectedByPref(const nsACString&);
|
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
static Prefs& ContentPrefs() {
|
|
|
|
MOZ_ASSERT(sInitialized);
|
|
|
|
return sContentPrefs;
|
|
|
|
}
|
|
|
|
|
|
|
|
static Prefs& ChromePrefs() {
|
|
|
|
MOZ_ASSERT(sInitialized);
|
|
|
|
return sChromePrefs;
|
|
|
|
}
|
|
|
|
|
2021-07-25 00:10:44 +03:00
|
|
|
static Prefs& PrintPrefs() {
|
|
|
|
MOZ_ASSERT(sInitialized);
|
|
|
|
return sPrintPrefs;
|
|
|
|
}
|
|
|
|
|
|
|
|
enum class PrefsKind {
|
|
|
|
Chrome,
|
|
|
|
Print,
|
|
|
|
Content,
|
|
|
|
};
|
|
|
|
|
|
|
|
static PrefsKind PrefsKindFor(const dom::Document&);
|
|
|
|
|
|
|
|
static bool ShouldUseChromePrefs(const dom::Document& aDocument) {
|
|
|
|
return PrefsKindFor(aDocument) == PrefsKind::Chrome;
|
|
|
|
}
|
|
|
|
|
2021-11-17 01:30:26 +03:00
|
|
|
static bool MayForceColors() { return !ContentPrefs().mUseDocumentColors; }
|
|
|
|
|
2019-03-07 00:34:30 +03:00
|
|
|
static const Prefs& PrefsFor(const dom::Document& aDocument) {
|
2021-07-25 00:10:44 +03:00
|
|
|
switch (PrefsKindFor(aDocument)) {
|
|
|
|
case PrefsKind::Chrome:
|
|
|
|
return ChromePrefs();
|
|
|
|
case PrefsKind::Print:
|
|
|
|
return PrintPrefs();
|
|
|
|
case PrefsKind::Content:
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
return ContentPrefs();
|
2019-03-07 00:34:30 +03:00
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
static bool sInitialized;
|
|
|
|
static Prefs sChromePrefs;
|
2021-07-25 00:10:44 +03:00
|
|
|
static Prefs sPrintPrefs;
|
|
|
|
static Prefs sContentPrefs;
|
2019-03-07 00:34:30 +03:00
|
|
|
|
|
|
|
static void Initialize();
|
|
|
|
};
|
|
|
|
|
|
|
|
} // namespace mozilla
|
|
|
|
|
|
|
|
#endif
|