1883997 - Firefox reports zero for layout/geometry queries on content in display:none iframes

Status: RESOLVED WONTFIX

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Not sure if this is a bug or not, but it's a behavior-difference with WebKit at least, so I figured I'd file to at least have a place to post a testcase and potentially hash things out.

STR:

1. Load attached testcase.

ACTUAL RESULTS:
The reported height is 0

MAYBE-EXPECTED RESULTS:
Maybe the reported height should be 300? That's the height that the element is styled to have, and it's what we get if I remove display:none at least.

Firefox and Chrome both give ACTUAL RESULTS.
WebKit gives MAYBE-EXPECTED RESULTS.

This came across my radar because twisniewski noticed https://github.com/WebKit/WebKit/commit/7d4f344fa9a70f3b92972faeaf1352c03d384b74 which is an optimization to this WebKit behavior (though the behavior predates that commit, if I'm understanding correctly)

In particular, the first few lines of that commit (from webkit committer alanbaradlay):

1. we do not construct renderers for “display: none” iframes
2. we do construct render tree for the “display: none” iframe’s content

we do #2 because JS may ask for geometry information on content inside a “display: none” iframe.

Firefox/Chrome do not do #2 as far as I know. I don't know for sure if any sites happen to break as a result of that.

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reference case 1

Here's a reference case where the iframe has its normal display value (and is just hidden using visibility instead). All browsers report 300 as the height of the body in the inner document here.

Comment 3

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

Firefox/Chrome do not do #2 as far as I know. I don't know for sure if any sites happen to break as a result of that.

(I posted https://bugs.webkit.org/show_bug.cgi?id=261741#c6 to ask about that.)

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Chrome did intentionally match our behavior, see https://github.com/whatwg/html/issues/1813 and https://github.com/w3c/csswg-drafts/issues/571.

WebKit seemed interested in following our behavior there, so I think this is wontfix? But feel free to leave open if you think there's value on keeping it open somehow.

Comment 5

[Daniel Holbert [:dholbert]]

Aha, right. Looks like WebKit has bug 107236 on file to align with Firefox/Chrome here.

Yeah, we can WONTFIX this.