Repository navigation
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent? #7213
Description
Consider this test-case:
<!doctype html>
<div style="color-scheme: light">
<img>
</div>
<div style="color-scheme: dark">
<img>
</div>
<script>
for (let img of document.querySelectorAll("img")) {
img.src = "data:image/svg+xml;base64," + btoa(`
<svg width="32" height="32" viewBox="0 0 32 32" xmlns="http://www.w3.org/2000/svg">
<style>
:root { color: blue }
@media (prefers-color-scheme: dark) {
:root { color: purple }
}
</style>
<rect fill="currentColor" width="32" height="32"/>
</svg>
`);
}
</script>Right now the rendering of those images match in all browsers, but one could argue that perhaps they should render differently (top blue, bottom purple)?
See also https://bugzilla.mozilla.org/show_bug.cgi?id=1764354, which is what prompted this discussion.
Activity
emilio commentedon Apr 13, 2022
cc #6988 which is somewhat related.
tabatkins commentedon Apr 14, 2022
Yeah, so basically you're asking if the used color scheme should automatically inherit into nested documents. That's a communication bit, which we try to avoid adding for cross-origin stuff, at least.
(#6988 would allow passing the color-scheme in purposely, if both the outer and inner page successfully handshaked.)
emilio commentedon Apr 14, 2022
Right. My reasoning for doing this for SVG images is that they cannot run script, etc, so it's a much more limited environment. But I guess you're right that they could trigger different image loads to exfiltrate that bit, potentially.
For the record, Gecko does inherit the color scheme into some frames (so that e.g., extension setting popups behave correctly if you have a dark Firefox theme but a light content theme). This is not exposed to regular
<iframe>s on websites, though.lilles commentedon Apr 20, 2022
The comment: #7213 (comment) confused me a bit since @emilio's example affects the preferred color-scheme, not the used color-scheme or color-scheme property directly.
This is about changing the preferred color-scheme in the SVG and the SVG root color-scheme would not be affected in another way than through the preferred color-scheme, right?
emilio commentedon Apr 20, 2022
Yeah, that's right.
css-meeting-bot commentedon Apr 20, 2022
The CSS Working Group just discussed
[css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?, and agreed to the following:RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)The full IRC log of that discussion
<fantasai> topic: [css-mediaqueries] Should prefers-color-scheme in SVG images be context-dependent?<fantasai> github: https://github.com//issues/7213
<fantasai> emilio: We got an interesting bug report in Firefox
<fantasai> emilio: When you have a Firefox theme that's dark, but OS theme is light
<fantasai> emilio: sites can't choose a reasonable favicon for dark mode
<fantasai> emilio: Suggestion is to make preferred-color-scheme for SVG images reflect the used color scheme
<fantasai> emilio: Then could have light+dark icons anywhere in your page, and then as long as your parent has the correct color-scheme will display correctly
<fantasai> emilio: Maybe worth making this more general
<fantasai> emilio: Tab seemed to have some reservations
<fantasai> TabAtkins: This makes a cross-origin communication bit, and we try to restrict those
<fantasai> TabAtkins: use case makes sense
<fantasai> TabAtkins: Just one more bit that you can use to talk to an iframe, and every bit counts
<fantasai> TabAtkins: but if that's considered not too much of a problem, then I'm fine with it
<fantasai> emilio: It's a communication channel in the sense that the SVG could request a different image or something
<fantasai> emilio: but SVG images don't run script
<fantasai> emilio: I think Chrome did something like this for iframes, don't know the details of that
<futhark> q+
<fantasai> emilio: If your iframe is in color-scheme: ? then you force a light background
<fantasai> futhark: Behavior for ?? is specified in the spec, that you set the background of the iframe if 'color-scheme' doesn't match parent
<fantasai> futhark: so you don't wind up with black on black or white on white
<TabAtkins> s/??/iframes with different color scheme than parent document/
<fantasai> futhark: Wanted to ask, has anyone asked for similar functionality for iframe?
<emilio> q+
<fantasai> futhark: or will there be other cases?
<Rossen_> ack futhark
<fantasai> futhark: other than SVG
<Rossen_> ack fantasai
<Zakim> fantasai, you wanted to ask why not restrict cross-origin
<fantasai> fantasai: If the concern is cross-origin, why not restrict to same-origin
<fantasai> emilio: Possible, but maybe awkward
<fantasai> emilio: wrt Rune's question, we actually do that for some frames
<fantasai> emilio: e.g. for extension popups in Firefox, they're just iframes inside a popup
<fantasai> emilio: we make those inherit the color scheme of Firefox in a similar fashion
<fantasai> emilio: so we already have this code to make it work for iframes
<fantasai> futhark: We do something similar for <select> popups in Chrome
<fantasai> futhark: If you have <select> with a color scheme, that affects the drop-down render
<fantasai> emilio: This seems generally a useful thing then
<fantasai> emilio: Main question is whether it's reasonable, given the issue Tab mentioned
<fantasai> emilio: I'm not sure I'm the right person to make that assessment
<fantasai> emilio: What about we ask people in privacy/security what they think about this?
<fantasai> emilio: If we accept it, then we can consider doing iframes as well
<fantasai> Rossen_: seems like a reasonable path forward
<fantasai> Rossen_: I think general consensus of the group leans towards the proposal
<fantasai> Rossen_: pending feedback from Security folks
<fantasai> Rossen_: So my proposal is to end the discussion here, and then get back to it as we gather more information
<TabAtkins> Always useful to resolve, if for no other reason than to have a neat conclusion easy to read at the end
<fantasai> fantasai: Could resolve that we want to do this, if reasonable from security standpoint
<fantasai> Rossen_: Any objection to record this as consensus of group?
<fantasai> PROPOSAL: Have prefered-color-scheme reflect 'color-scheme' on the element in the embedding document, to the extent acceptable from security standpoint
<fantasai> RESOLVED: Have prefered-color-scheme reflect 'color-scheme' on the embedding element in the embedding document, to the extent acceptable from security standpoint (pending security review)
emilio commentedon May 13, 2022
I just realized that in non-Gecko browsers, this bit of information is already passed down to the right process due to #4772.
Bug 1738380 - Draw backgrounds of iframes with mismatched embedder co…
Bug 1738380 - Draw backgrounds of iframes with mismatched embedder co…
emilio commentedon Jun 1, 2022
Bringing this up again because I was working on this in https://bugzilla.mozilla.org/show_bug.cgi?id=1738380, and I realized that there's no way to guarantee a transparent background of an iframe without hard-coding the color-scheme.
That is: an iframe with
<meta name="color-scheme" content="light dark">that ideally has both light and dark mode, can be guaranteed to be transparent, if e.g. the user prefers dark theme but it's embedded on a light page.That's a bit unfortunate, there's a variety of regressions from my work that would ideally be fixed by just having
<meta name="color-scheme" content="light dark">(like https://bugzilla.mozilla.org/show_bug.cgi?id=1771047 / https://bugzilla.mozilla.org/show_bug.cgi?id=1772168), but which instead have to coordinate between embedder and embedee.@smfr / @lilles / @tabatkins, is there any chance you could ping some of the WebKit / Blink security folks about this (since that's the major concern here)? I'll do the same for Mozilla's security folks, but my guess is that since the relevant information is already in the target process, it's not really a big leak...
heycam commentedon Jun 7, 2022
Would this affect SVG images used as CSS
<image>values too?11 remaining items
emilio commentedon Aug 24, 2022
We resolved for iframes in #7493 didn't we?
tabatkins commentedon Aug 25, 2022
Ah, we did! Thanks, I'll fix it up then.
bramus commentedon Jul 17, 2023
Closing this issue as the necessary edits have made it in. Added the necessary labels to #7493, which is concerned with the behavior for iframes.
Make icons react to color-scheme properly.
Make icons react to color-scheme properly.
Make icons react to color-scheme properly.
Make icons react to color-scheme properly.
ui: cope with SVG limitations of WebKit/Safari based browsers
Bug 1738380 - Draw backgrounds of iframes with mismatched embedder co…
Bug 1779457 - Make prefers-color-scheme of SVG images match embedder …
[css-color-adjust-1] Rework color scheme stuff to reflect f2f resolut…