1935189 - `container-type: inline-size` in outer document prevents resize events from firing when iframe changes from `display:none` to `display:block`

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: (iframe for use in testcase)

STR:

1. Load testcase.
2. Open your Web Console (F12) (optional)
3. Click the "Click" button in the testcase.

EXPECTED RESULTS:

• The iframe should appear with "Resize count: 1".
• console.log should show "IFRAME RESIZED" when you click the button.

ACTUAL RESULTS:
The iframe appears with "Resize count: 0"

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: reference case 1 (with "container-type: inline-size" removed)

Comment 3

[Daniel Holbert [:dholbert]]

emilio: hoping you can take a look, as this seems to be a container-queries issue (that being the only difference between the testcase & reference case).

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (reduced a bit)

Here's a somewhat more reduced/standalone testcase.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: reference case 2

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 3 (container-type moved to a non-ancestor element)

I just noticed in bug 1933229 that this reproduces even if the container-type element isn't an ancestor of the iframe. Here's a testcase to demonstrate that.

(It doesn't matter whether the element comes before or after in the DOM.)

Comment 7

[Daniel Holbert [:dholbert]]

As noted in bug 1933229 comment 8: this is a regression from when we enabled container queries (because the bug is specific to container-type: inline-size). That happened in this Nightly range:
Last good: 2022-11-20
First bad: 2022-11-21
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d2c6287383301f29964047d5c718640eb4bbcccb&tochange=a29b80b107103df84e493008e420e30aea857da1

In builds from shortly after that time period, you can avoid the bug by toggling layout.css.container-queries.enabled to false (just as the reference cases here avoid the bug by removing the container-type styling).

Comment 8

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1935189 - Don't make frame initial viewport size depend on whether it's been laid out. r=dholbert

This is rather tricky / unfortunate, but this is the low-risk fix for
now. The issue is as follows:

When we construct a subdocument frame, we try to show its viewer by
using a script runner which will call ShowViewer().

If ShowViewer() gets called before the subdoc frame gets laid out
(has the NS_FRAME_FIRST_REFLOW bit set), we pick an (arbitrary) 10x10
device pixel size, and initialize the page with that viewport.

Then, eventually, the frame gets laid out to the correct size and fires
a resize event.

If we have container queries around, we need to lay out the page while
styling, which causes the layout to happen before the script blocker
checkpoint, and thus the viewport to get initialized with the right size
to begin with.

This generally shouldn't be bad, but pages google chat seems to rely on
this resize event (and the divergence being caused by container queries
is rather unfortunate).

For now, do the low risk fix of always using the "initial" subdoc frame
size to show the viewer.

We should ideally sort this out better. Even our "good" behavior is
quite bizarre (e.g, I'd expect going from display: block to none to
trigger a resize event and the viewport to go back to 0... As you noted,
chrome's inner layout sizes do change when the frame is display: none).

But it seems worth to land this at least in the interim.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

Sorry for the lag, see the commit message for diagnostic and details... This seems all rather messy, but for now I restored our no-container-query behavior...

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0c612ed5d669
Don't make frame initial viewport size depend on whether it's been laid out. r=dholbert

Comment 11

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/49955 for changes under testing/web-platform/tests

Comment 12

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/0c612ed5d669

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 14

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

The patch landed in nightly and beta is affected.
:emilio, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Comment 15

[Emilio Cobos Álvarez (:emilio)]

I think given Google has a workaround and this is a rather subtle area, we can let this ride the trains, but let me know if you disagree.

Comment 16

[Daniel Holbert [:dholbert]]

Yup, agreed.

Comment 17

[Daniel Holbert [:dholbert]]

I just verified that this is fixed in Nightly 136.0a1 (2025-01-08) using the attached testcases, too. --> updating status.