This is most certainly [QTBUG-89753] prefers-color-scheme does not seem to work - Qt Bug Tracker, fixed by Add back prefers-color-scheme support (I89552671) · Gerrit Code Review.

I didn't really understand what this was about (as my test for it still seems to pass) - but now that I have a reproducer, I'll take a look if there's some kind of workaround I could add.

From a quick test, this seems to work:

diff --git i/qutebrowser/browser/webengine/darkmode.py w/qutebrowser/browser/webengine/darkmode.py
index ffc14c7e3..7f4d31c0b 100644
--- i/qutebrowser/browser/webengine/darkmode.py
+++ w/qutebrowser/browser/webengine/darkmode.py
@@ -273,6 +273,8 @@ def settings() -> Iterator[Tuple[str, str]]:
         # will need to be set to '0' instead:
         # https://chromium-review.googlesource.com/c/chromium/src/+/2232922
         yield "preferredColorScheme", "1"
+    else:
+        yield "preferredColorScheme", "2"
 
     if not config.val.colors.webpage.darkmode.enabled:
         return

which can be replicated by setting -s qt.args '["blinkSettings=preferredColorScheme=2"]' - though that might interfere with dark mode settings, not sure.

which can be replicated by setting -s qt.args '["blinkSettings=preferredColorScheme=2"]' - though that might interfere with dark mode settings, not sure.

Uhm, it doesn't seem to work with 1.14.1. I'll try later with 2.0.

My bad - that should be blink-settings, not blinkSettings.

I tried with this patch on 1.14.1

diff --git a/qutebrowser/config/qtargs.py b/qutebrowser/config/qtargs.py
index 06df54a2f..89f01da49 100644
--- a/qutebrowser/config/qtargs.py
+++ b/qutebrowser/config/qtargs.py
@@ -79,15 +79,17 @@ def _darkmode_prefix() -> str:
 
 def _darkmode_settings() -> typing.Iterator[typing.Tuple[str, str]]:
     """Get necessary blink settings to configure dark mode for QtWebEngine."""
-    if (qtutils.version_check('5.15.2', compiled=False) and
-            config.val.colors.webpage.prefers_color_scheme_dark):
+    if qtutils.version_check('5.15.2', compiled=False):
         # With older Qt versions, this is passed in qtargs.py as --force-dark-mode
         # instead.
         #
         # With Chromium 85 (> Qt 5.15.2), the enumeration has changed in Blink and this
         # will need to be set to '0' instead:
         # https://chromium-review.googlesource.com/c/chromium/src/+/2232922
-        yield "preferredColorScheme", "1"
+        if config.val.colors.webpage.prefers_color_scheme_dark:
+            yield "preferredColorScheme", "1"
+        else:
+            yield "preferredColorScheme", "2"
 
     if not config.val.colors.webpage.darkmode.enabled:
         return

It works but colors.webpage.darkmode = true it breaks again.

I'll need to check if there's something I can do about that. Either way, this will be fixed properly with the next QtWebEngine release.

Removing this from v2.0.2 for now as it's not a regression in qutebrowser.

Uhm, it will probably take a long while since 5.15.3 is unsuable due to the (stupid) licensing and 6.0 is not stable yet.

Like mentioned in Qt's announcement, Qt WebEngine 5.15.3 will be a normal open source release.

After thinking about it a bit more, I don't think the fix above is correct. The default by QtWebEngine/Chromium isn't "light" - it's auto-detection based on the OS' colorscheme.

I don't think we can easily replicate that in qutebrowser, but I suppose we could replace the colors.webpage.prefers_color_scheme_dark boolean by a colors.webpage.prefers_color_scheme setting taking light, dark and auto (falls back to light with QtWebEngine 5.15.2 as a workaround for the bug).

Makes sense to me, given in CSS prefers-color-scheme is really three-valued: light, dark, no-preference.

Note that the no-preference option was removed from the standard:

This feature, like the other prefers-* features, previously had a no-preference value to indicate an author not expressing an active preference. However, user agents converged on expressing the "default" behavior as a light preference, and never matching no-preference.

However, Chromium reads a system-wide setting, so I'd like to keep the "auto" value as well, rather than hardcoding "light" as default.

Could you try the dev branch? I didn't merge it to master yet because a test is still failing, but I think this should now be fixed (or worked around) to the extend that it's possible.

I just tested the dev branch with Qt 5.15.2 (chromium 83): preferred_color_scheme doesn't seem to work: I tried setting every possible value but I'm always getting the no preference version. I tested again with this:

qutebrowser -T -s colors.webpage.preferred_color_scheme dark test.html

Note that this works:

qutebrowser -T -s qt.args '["blink-settings=preferredColorScheme=2"]' test.html

Works fine for me. Make sure you do something like git fetch origin; git reset --hard origin/dev (note that this will discard any local changes in the git repo!).

If it still doesn't work after that, can you please show your :version information again?

Sorry, I figured I accidentally used an old nixpkgs checkout with pyqtwebengine at 5.15.0. Yes, I can confirm it works.

No worries, thanks for the update! I've pushed everything to master now.

I took another look at getting the workaround to work with darkmode, but no luck. No idea what causes it to break exactly, but it doesn't look like something qutebrowser could influence, unfortunately.

I've also tested QtWebEngine 5.15.3 (or rather, the current 5.15 branch). There, they work well together again, but the behavior changed compared to Qt 5.14 and 5.15.0: The colors.webpage.preferred_color_scheme setting is ignored as soon as colors.webpage.darkmode.enabled is set, and "light" always seems to be assumed (and then inverted by the darkmode filter).

This looks like a Chromium bug, which I've reported here: 1177973 - "Force Dark Mode for Web Contents" breaks "prefers-color-scheme: dark" - chromium

Thank you for opening the upstream bug.

It looks like that behavior is intended, unfortunately: https://bugs.chromium.org/p/chromium/issues/detail?id=1177973#c4

On the positive side, that gave me a possible hint for #5542 🙂

I just came across this change.
It looks like they've changed their mind, am I getting this right?

@rnhmjoj Better late than never: I can indeed confirm that with the upcoming QtWebEngine 6.4, the behavior is back to what it was on Qt 5.14 and 5.15.0/.1: da10f19 🎉

I'm not sure https://bugs.chromium.org/p/chromium/issues/detail?id=1177973 was really fixed.
I just tested with qutebrowser (QtWebEngine 6.5.1, chromium 108) and chromium 114.
In both cases websites with a dark mode but without <meta name="color-scheme" content="dark light"> are displayed in light mode and then inverted. What did you do exactly to get the correct behavior?

I've been testing with prefers-color-scheme.html and something like:

qutebrowser --temp-basedir -s colors.webpage.preferred_color_scheme dark -s colors.webpage.darkmode.enabled true tests/end2end/data/darkmode/prefers-color-scheme.html

• QtWebEngine 5.15.14 and both arguments: "light preference detected", (slightly) lighter shade of grey
• QtWebEngine 6.5.1 and only colors.webpage.darkmode.enabled: same as above
• QtWebEngine 6.5.1 and both arguments: "dark preference detected" and (slightly) darker shade of grey

It seem there is some recoloring going on, the preference are working corretly, though.

<html>
<head>
  <style>
    @media (prefers-color-scheme: dark) {
      :root { 
        --bg1: #181b20;
        --bg2: #765636;
        --fg1: #744b40;
        --fg2: #435861;
      }
    }
    @media (prefers-color-scheme: light) {
      :root { 
        --bg1: #f5e7de;
        --bg2: #744b40;
        --fg1: #992e2e;
        --fg2: #992e2e;
      }
    }
    body { font-size: 30mm; background: black; }
    .a {
      color: var(--fg1);
      background: var(--bg1);
    }
    .b {
      color: var(--fg2);
      background: var(--bg2);
    }
  </style>
</head>
<body>
  <span class="a">AAA</span>
  <span class="b">BBBB</span>
</body>
</html>