[css-mediaqueries] Precisely define which media features an undisplayed page has.

[emilio]

Gecko has never evaluated media features in display: none iframes, which causes interop issues (because matchMedia wouldn't work and pages would get confused).

I'm fixing that (https://bugzilla.mozilla.org/show_bug.cgi?id=1490401), but that raises the question of what should the values for the different media features be in this case.

I know that people rely at least on having a viewport of 0x0, and a device-size that doesn't always evaluate to false: https://bugzilla.mozilla.org/show_bug.cgi?id=1519463

With my patch, all engines agree on having a 0x0 viewport, afaik. But Gecko will also report 0x0 device size (in which screen is a display: none iframe displayed?). I don't think we have a compat constraint on that, but I think we should define what the expected result is.

In general, Gecko will just return dummy values for things that depend on the device. In particular:

• device-size will be 0x0
• media type will be screen.
• DPR will be 1.0
• color will be 8.

I think that's reasonable. We could do a bit more effort for and check the parent document for iframes that are children of displayed pages, but for pages that are not displayed (e.g. have been navigated away, or are in the bfcache) we don't know what is the value for those in a multi-display situation anyway.

What do other engines do? What should they do?

/cc @lilles

[lilles]

Seems Chrome matches DPR (resolution) and device-size as if the iframe was rendered, with viewport size matching (0,0). I don't know how/if queries depending on device works for multi-screen/monitor case.

[css-meeting-bot]

The CSS Working Group just discussed [css-mediaqueries] Precisely define which media features an undisplayed page has., and agreed to the following:

• RESOLVED: Do testing in this area and specify values for this case

The full IRC log of that discussion

<dael> Topic: [css-mediaqueries] Precisely define which media features an undisplayed page has.
<dael> github: https://github.com//issues/3800
<dael> florian: Display:none iframes can run scripts. If you run script you can run MQs. Spec doesn't say what to do in that case
<dael> florian: There are sites that depend on this and try to run it. Gecko is trying to find answers that don't make web crash
<dael> florian: Do we want to define this? Yes if web depends on it. What's best way to find answer? Is it in L4 or L5?
<dael> florian: Is emilio on?
<fantasai> Put it in L5, if it stabilizes and we want to pull it down to L4 later we can do that
<dael> florian: emilio suggested dummy values that don't depend on anything. That way you can answer something
<dael> florian: Appears Chrome answers non-dummy for some MQ. Resolution for example they answer for the doc hosting the iframe
<dael> florian: Proper is write tests
<dael> astearns: Is that bad? SHould iframes have access to that when they're display:none?
<dael> TabAtkins: I suspect there might be issues or data structures not created. Other than that I agree pulling information from same screen as document is fine. If iframe is displayed it's on the same screen and gets answers
<dael> florian: But if it isn't displayed it doesn't need to know. o maybe privacy leak. If you display it sure you get it.
<dael> TabAtkins: I don't think we shoudl conclude display:none is info boundary
<dael> florian: If there's a use to expose the parent sure. If it's just because why not we could also not expose why not.
<dael> rune: We're not exposing from parent document. I think we get it from frame structure. We're getting it for frame that's display:none b/c we have objects for the frame. It's not exactly parent document but directly via the frame
<dael> florian: Asking in a different way, is there a valid use for a display:none iframe to know screen resolution?
<dael> rune: no
<dael> TabAtkins: Really? I'd think it running scripts in preparing t odsipaly might want information
<dael> rune: true
<dael> TabAtkins: If it's primarily display:none sure, but you can't tell
<dael> Rossen: Is there a use case here or jsut about givign correct defaults
<dael> florian: Mozilla had crash bugs. They were responding with wrong thing where frames caused crash
<dael> Rossen: For me similar to how we resolved to answer gCS values for docs in that category. Seems we should stick to whatever defaults hsould be there and make them stable
<dael> florian: Dummy value like emilio suggested?
<emilio> gCS is defined to return an empty declaration, with length = 0
<bkardell_> q+
<dael> Rossen: Yeah. Exactly way did it for gCS. Return a bunch of default intiial values. Should match that. If we don't we're opening inconsistency between
<dael> smfr: Some compat risk. Prefer we test existing browsers and than decide if we want to change from current impl. Will be hard b/c we don't know what a display:none iframe is doing now
<astearns> ack bkardell_
<dael> TabAtkins: I thought some compat against 0 by 0 but it's against only false devices. 0x0 fixes one of emilio bugs
<emilio> Right, 0x0 is alright. Its "never match" what breaks sites
<dael> bkardell_: smfr said my point. I'm surprised by this. Seems unfortunate that it's surprising and I'd like to know why it is and if necessary to be surprising. BUt we can't break anything so understanding today is good first step
<astearns> ack fantasai
<florian> q+
<dael> fantasai: emilio said 0x0 is alright and never matches breaking site
<dael> astearns: For this case that we know of. So we do need a fix for that.
<dael> astearns: Good to have interop.
<TabAtkins> my proposed resolution: Attempt to fix MQs in non-displayed iframes to specific values, to be determined by testing.
<dael> astearns: I think we need testing before we decide what's possible in terms of interop values here
<dael> florian: I suggest for MQ specified but not impl I just pick ad efualt so that when they're implemented we don't get complicated interop. For those that exist we have to test
<dael> florian: That's tricky b/c I don't have a display:P3 device
<dael> TabAtkins: Someone does
<dael> TabAtkins: I suggest we add default value to MQ blocks and make that required in bikeshed
<dael> florian: Yep
<Rossen__> +1 to mq default values
<dael> astearns: Obj to do testing in this area and specify values for this case
<dael> RESOLVED: Do testing in this area and specify values for this case