1795581 - Make prefers-color-scheme configurable for private browsing mode

Status: NEW

(Firefox :: Theme, enhancement)

Description

[Ellie]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:106.0) Gecko/20100101 Firefox/106.0

Steps to reproduce:

browser.theme.dark-private-windows set to false doesn't appear to be working, also maybe that should default to true. I find this unfavorable personally less so from a privacy angle (although I'm sure that would bother others), but rather that as a web developer I need a way to see a site "untouched" by personalizations and logins to get a reliable glimpse of how it looks like to others being first time visitors, so having everything switch to dark mode and other such changes gets in the way of that. But also from a privacy design angle, this doesn't seem like it should be.

1. Install Firefox on a GNOME 3 Linux desktop via the Mozilla x64 tarball version, make sure "Appearance" > "Style" is set to GNOME 3's "Dark" mode.

2. Open Firefox, open private window, visit any site that checks dark mode via CSS. Due to being private and anonymous I would expect it to behave like under non-dark mode, but it doesn't.

3. Go to about:config, search for dark mode settings and find browser.theme.dark-private-windows and set it to false - which I think should be the default anyway.

4. Close private window, reopen it. (Don't restart Firefox as a whole.) Revisit the site that adjusts to dark mode via CSS. You'll see that even now after the explicit about:config change, it will still react to your dark mode setting.

Actual results:

browser.theme.dark-private-windows defaults to true, and setting it to false doesn't actually make websites in private windows behave like the desktop themeing is always non-dark

Expected results:

browser.theme.dark-private-windows defaults to false and actually makes websites in private mode pretend there is no dark mode

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Gtk' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

We can't render both light and dark windows with the native theme fwiw (due to GTK limitations). But even with another theme I don't think looking at the relevant code it's supposed to turn private windows light if it's set to dark. This might be WONTFIX.

Comment 3

[Ellie]

Maybe such a setting should be introduced then?

We can't render both light and dark windows with the native theme fwiw

I don't get that remark. Couldn't you decide to pass "theme is light" to the CSS engine in private windows always? (And I think you should!) Or how is that related to GTK+? And I'm assuming with JavaScript you could detect this dark theme CSS change and finger print the user better, so it does seem privacy relevant. If you're talking about how input elements inside the page were rendered, I recall there being multiple tickets to not use native widgets for that anyway, so I'm guessing the dependency to GTK+ also for that might go away? I have no idea what I'm talking about though, I don't work on Firefox I just follow some tickets.

In any case, I wasn't talking about the surrounding browser UI but the page, if that wasn't clear. I don't care if the Firefox private WINDOW remains dark, actually I think that would be highly expected, but the PAGE CONTENT in a private window maybe shouldn't be in dark mode then. At least that's what I'm suggesting!

Comment 4

[Ellie]

I guess I didn't clarify this well: I assumed "dark-private-windows" was a shorthand for "dark-private-window-page-contents-when-system-ui-theme-is-dark". Since it's not, that's why my ticket description may sound confused.

Comment 5

[Emilio Cobos Álvarez (:emilio)]

It's not, that pref actually doesn't change the prefers-color-scheme value, it changes the browser theme.

We use some native GTK widgets in the native theme like the toolbar and maximize / minimize / close buttons. GTK can't load two themes at the same time (nor switch between them efficiently) so we can't render a light and dark natively-themed browser window side-by-side.

Comment 6

[Emma Zühlcke [:emz]]

Thanks Emilio!

As you said we don't touch the content prefers-color-scheme value, so this change should have no (web-exposed) privacy implications. Both normal and private browsing will expose the same prefers-color-scheme value. Though generally I can see how exposing the system color scheme to the site increases the fingerprinting surface a bit.
For testing prefers-color-scheme developers can use the color scheme simulation feature in the devtools.

I'll leave closing this up to the triage owner. Ellie, does this address your concerns or should we keep this bug open / update it?

Comment 7

[Ellie]

Well, as specified above I think the system color scheme just shouldn't be passed to websites in private mode by default. Or at least a way to permanently turn that off would be nice. After all, I can do the same for addons/extensions, and pretty much all other sort of browser features that would make the site react to me in a personalized way for private mode, so this feels a bit like an oversight. However, if you think that's not a feature worth including feel free to close the ticket.

Comment 8

[Emma Zühlcke [:emz]]

We do have the privacy.resistFingerprinting pref which makes it so Firefox always sends the light color scheme. However, that pref is global and it isn't really meant to be used in Firefox and breaks a bunch of other things in favor of privacy. Then there is layout.css.prefers-color-scheme.content-override which unfortunately also applies to both window types.

Personally I'm not opposed to separate theme (and prefers-color-scheme) preferences for normal and private browsing.