User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0

Steps to reproduce:

Consider visiting a page with an adaptive favicon, by which I mean an SVG file with an inline (prefers-color-scheme: dark) media query.
I use Firefox's dark theme, but have set layout.css.prefers-color-scheme.content-override to 2 (system), as I like having a dark navbar but don't want dark mode on my web pages during the day.

Actual results:

The favicon's media query is not activated, keeping it in light mode, on the theme's dark background, rendering it invisible (black on dark gray).

Expected results:

The favicon should have changed to adapt to the tab's background color, and not the setting used to render the page. I believe favicons should always assume a layout.css.prefers-color-scheme.content-override set to 3 (browser).

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

Emilio, is this easy to fix?

Non-trivial, but perhaps not so complicated, I'd need to page in a bunch of our context-properties work. One could argue that this is a more general problem though: https://github.com/w3c/csswg-drafts/issues/7213

Just as a sidenote, GitHub's favicon is a good example of this.

Github's favicon wouldn't be helped by this afaict. It doesn't have any media queries (it switches between https://github.githubassets.com/favicons/favicon.svg and https://github.githubassets.com/favicons/favicon-dark.svg using JS, afaict)

This allows favicons to respect the user theme even when it doesn't
match the content theme.

(In reply to Emilio Cobos Álvarez (:emilio) from comment #5)

Github's favicon wouldn't be helped by this afaict. It doesn't have any media queries (it switches between https://github.githubassets.com/favicons/favicon.svg and https://github.githubassets.com/favicons/favicon-dark.svg using JS, afaict)

Ah, my bad, I didn't think to check, just noticed the behavior was the same.

Backed out the fix that was wrong. It actually started from Bug 1761999.

Sorry about this.

https://hg.mozilla.org/mozilla-central/rev/4a0fda18680a

:emilio checking this does not now open up a new fingerprintable vector?

RFP already deals with prefers-color-scheme doesn't it? For non-rfp, yes, potentially you could request an image based on this and detect whether the user has a theme mismatched from the content theme. However there's no way otherwise to get the right favicons in this case, afaict.

some quick testing on nightly, I am using ui.systemUsesDarkTheme = 1 which is ignored by RFP, but yes RFP should return prefers-color-scheme as light

• I used github for my test page
• toggling RFP toggles the tab icon (wait 5 seconds or so for sync to catch up)
• RFP on (so light), the tab icon is dark, but creating a bookmark uses a light icon
• RFP off (presumably dark), the tab icon is light, creating a bookmark uses a light icon

IS something mismatched going on here with tab vs bookmark (hard to tell with bookmark icons, I did sanitize Chrtl-Shift-Del everything and remove the existing bookmark - but I do have one other github bookmark link, just not that specific URL - maybe I need to use a new profile)

For non-rfp, yes, potentially you could request an image based on this and detect whether the user has a theme mismatched from the content theme

So the answer is yes then? Given we can detect prefers-color-scheme, we can know detect the theme color (binary: match vs not-match?) yes/no?

What is your test-case? But yes, you can detect favicon's prefers-color-scheme vs. regular-website prefers-color-scheme.

What is your test-case?

I didn't build one yet. I pinged :tjr via email but given RFP seems to do the right thing with a tab-icon, then it doesn't concern RFP. But given the bookmark didn't seem to follow, I'm not sure

But yes, you can detect favicon's prefers-color-scheme vs. regular-website prefers-color-scheme

So, non-RFP at least, this adds a binary fingerprint metric, yes? Unless I've misunderstood something.

Are you sure the favicon you're using uses prefers-color-scheme at all? But again, yes, this adds a bit of information that the website didn't have before, when you have mismatched firefox and content themes.

Hi Emilio, I'm trying to work out the documentation impact of this for FF101.

As I understand it

• prefers-color-scheme is a media query that provides styling if the user has set a preference for dark theme (or light, which they also get by default). This preference might be set by the user based on the OS mode or the browser mode/theme.
• They have an SVG with inline prefers-color-scheme for dark formatting.
• They have set layout.css.prefers-color-scheme.content-override to 2 (system). The system is set to light mode so the prefers-color-scheme for dark mode should not be triggered. Though I guess it depends what "content" means in "content-override".
• They have set Firefox's dark theme so the prefers-color-scheme styling should be triggered.
• It is not clear to me what layout.css.prefers-color-scheme.content-override should override, but I think the argument is that this applies to content in the page, and not the favicon which is part of the page. Is that right?
• Or it could be that they are saying that a favicon should always respect what the chrome is using for a theme, and that will be the browser setting.

Is that all about right?

So how would you characterise the change? Is it that layout.css.prefers-color-scheme.content-override does not apply to elements displayed in the chrome? Or is it the more specific case that a favicon should always respect the browser theme?

Ultimately I'm trying to work out whether this is an update to prefers-color-scheme or documentation on favicons, or something else.

As an aside, I also saw that you have generalized this in https://bugzilla.mozilla.org/show_bug.cgi?id=1779457 for FF105. From your description in https://github.com/w3c/csswg-drafts/issues/7213 it looks like color-scheme provides the context that an element prefers (say) dark that then triggers the prefers-color-scheme media query on the element.

• Previously the colour-scheme might have been ignored by the prefers-color-scheme , which would have only looked at the device or browser theme - is that right?
• Is there other context provided anywhere? or is this just colour-scheme
• Might this styling apply to things other than SVG? It sounds pretty general!
• Assuming that's correct then the documentation update for this would be to prefers-color-scheme.

(In reply to Hamish Willee from comment #20)

Is that all about right?

Yeah.

So how would you characterise the change? Is it that layout.css.prefers-color-scheme.content-override does not apply to elements displayed in the chrome? Or is it the more specific case that a favicon should always respect the browser theme?

Well, more generally, SVG images' color-scheme preference should respect the embedder. That's what https://github.com/w3c/csswg-drafts/issues/7213 is about. So in this bug I made that change only for images in the firefox UI, but we plan to expand it more generally as per the discussion in that github repo.

• Previously the colour-scheme might have been ignored by the prefers-color-scheme , which would have only looked at the device or browser theme - is that right?

Right, previously they were independent.

• Is there other context provided anywhere? or is this just colour-scheme

No

• Might this styling apply to things other than SVG? It sounds pretty general!

Right now, no. Per https://github.com/w3c/csswg-drafts/issues/7493, it will apply to iframes as well (I hope to get to that for 105).

• Assuming that's correct then the documentation update for this would be to prefers-color-scheme.

That's correct, I think, though perhaps a note for favicons until we ship the change to SVG images / iframes in 105 is preferred.

FF101 docs for this issue can be tracked in https://github.com/mdn/content/issues/19450. Plan is to just do an update to FF101 release note about favicons and look at this more fully in FF105 as Emilio suggested.