Closed Bug 1689099 Opened 3 years ago Closed 3 years ago

ResizeObserver callback doesn't reliably fire, when observing an element in an iframe subdocument (with the observer registered in outer document)

Tracking

()

Status:

RESOLVED FIXED

Milestone:

93 Branch

Tracking Flags:

Tracking

Status

firefox93

---

fixed

People

(Reporter: alessandro.dolci, Assigned: boris)

References

Details

Attachments

(5 files)

resize-observer-iframe.html 3 years ago Alessandro Dolci 1.97 KB, text/html		Details
(helper file for the iframe in testcase 2) 3 years ago Daniel Holbert [:dholbert] 130 bytes, text/html		Details
testcase 2 3 years ago Daniel Holbert [:dholbert] 1.32 KB, text/html		Details
testcase 3 (reports callback count via a label on the page) 3 years ago Daniel Holbert [:dholbert] 1.29 KB, text/html		Details
Bug 1689099 - Schedule resize observers for the whole browsing context tree. 3 years ago Boris Chiou [:boris] 48 bytes, text/x-phabricator-request		Details \| Review

Alessandro Dolci

Reporter

Description

•

3 years ago

Attached file resize-observer-iframe.html — Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/88.0.4324.96 Safari/537.36

Steps to reproduce:

I defined an iframe containing a document with variable height, and used the ResizeObserver API to listen for size changes on the iframe content, in order to modify the container iframe accordingly.

Here you can see it in action: https://jsfiddle.net/ujxkre85/ (I'm including this example as an attachment, too).
While the content height gets incremented, the iframe element is expected to have its "style.height" property updated by callback function of the observer.

Actual results:

ResizeObserver callback doesn't get triggered when it should.
Nonetheless, it does seem to get called if I manually resize my browser window, or if I inspect the element/bring up the dev console.

Expected results:

Height changes on the observed element (the content body of my iframe) should always invoke the callback held by the observer, passing instances of ResizeObserverEntry as arguments.

Comment hidden (typo)

Comment on attachment 9199521 [details]
resize-observer-iframe.html

><html>
>    <head>
>        <script type="text/javascript">
>            window.addEventListener("load", () => {
>                const iframeElement = document.getElementById("container");
>
>                // Periodically increment the height of the content
>                let currentHeight = 0;
>                window.setInterval(() => {
>                    if (currentHeight < 2000) {
>                        currentHeight += 100;
>                        iframeElement.contentWindow.document.body.style.height = `${currentHeight}px`;
>                    }
>                }, 1000);
>
>                // React to content height changes and adapt the size of the iframe
>                const resizeObserver = new ResizeObserver(entries => {
>                    entries.forEach(entry => {
>                        console.log(entry);
>                        iframeElement.style.height = `${entry.target.scrollHeight}px`;
>                    });
>                });
>                resizeObserver.observe(iframeElement.contentWindow.document.body);
>            });
>        </script>
>    </head>
>    <body>
>        <div>
>            <iframe id="container" src=""></iframe>
>        </div>
>    </body>
></html>
>

Alessandro Dolci

Reporter

Updated

•

3 years ago

OS: Unspecified → Linux

Hardware: Unspecified → x86_64

BugBot [:suhaib / :marco/ :calixte]

Comment 2

•

3 years ago

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Layout

Product: Firefox → Core

Daniel Holbert [:dholbert]

Comment 3

•

3 years ago

Thanks for the bug report! (Administrative note: I tagged comment 1 -- which is quite tall due to having the full text of the attachment -- as typo, simply to auto-collapse it, so it doesn't take up too much of the bug page. Something must've gone wrong during the attachment-posting step to end up with the full text in a comment as well, but it's not a problem with it collapsed.)

I can reproduce, and this appears to be a valid bug. From looking at how it's behaving, it looks like we only fire the resize-observer callback in response to a layout flush in the same document; but to support this cross-document scenario (with same-origin allowing cross-document DOM access), we need to fire these observers a bit more eagerly, too.

ni=boris for FYI, but not sure about prioritization vs. other things you're working on at the moment.

Severity: -- → S3

Status: UNCONFIRMED → NEW

Ever confirmed: true

Flags: needinfo?(boris.chiou)

OS: Linux → All

Hardware: x86_64 → All

Version: Firefox 84 → Trunk

Daniel Holbert [:dholbert]

Comment 4

•

3 years ago

Attached file (helper file for the iframe in testcase 2) — Details

Daniel Holbert [:dholbert]

Comment 5

•

3 years ago

Attached file testcase 2 — Details

Here's a second testcase with a few changes, to perhaps make this easier to see:

I've used an actual separate HTML document for the iframe. (hosted/accessed via the same origin using the bugzilla attachments subdomain specific to this bug, so that we can access it from the testcase)
I've adjusted things a bit so that it's a regular div whose size is changing, and so that the resize observer produces a visual color change, when it fires.

EXPECTED RESULTS: The iframe border should change every time the div is resized.
ACTUAL RESULTS: The iframe border only changes when I resize my viewport (e.g. if I open/close devtools, or drag the devtools resizer bar).

I assume the viewport-sensitivity is just because this causes a reflow in the outer document which flushes that document's resize observers, or something along those lines.

Chrome gives EXPECTED RESULTS.

Daniel Holbert [:dholbert]

Comment 6

•

3 years ago

Attached file testcase 3 (reports callback count via a label on the page) — Details

Daniel Holbert [:dholbert]

Comment 7

•

3 years ago

•

Edited

Actually, it's not that we're queuing up observers and only firing them at a certain point. Rather, it's that we only check for a size change (and save the element's current size for future comparisons) when the outer document has a reflow. Or something like that.

i.e. if you load testcase 3, and resize the document (e.g. ctrl+shift+k to open/close devtools) at particular times where the inner div is always the same size (e.g. when it's at its smallest), then the resize-observer-callback count never increases. This indicates that we don't think the element has resized. (Which makes some sense, from this imagining of how this bug is happening; at the moments where we're getting layout in the outer document, this element is still the same size as we saw it before.)

Daniel Holbert [:dholbert]

Updated

•

3 years ago

Depends on: 1272409

Alessandro Dolci

Reporter

Comment 8

•

3 years ago

Thank you very much for considering this!

First of all, I screwed up with the attachment file, I tried to edit it after submitting the post to remove some unwanted text at the end of it, but ended up adding that useless comment and leaving the attachment in the same broken state. My bad, I didn't know it's not possible to delete submitted content, I'm sorry!

Regarding the bug, you're right, I totally forgot to mention that this is totally working in other browsers (i.e. Chromium).

To further expand on my initial report, hoping to give some more elements to reason about, I noticed that pausing the execution with a breakpoint inside the content resize function (the setInterval callback in our testcases) makes everything work as expected. Maybe this has something to do with what you were reasoning about, e.g. resuming execution from a breakpoint causes a re-render of the outer layout, and/or a check for size changes, which in turn triggers the observer, but of course I'm just taking wild guesses here.

Let me know if you need more clarifications, I'm glad to help!

Daniel Holbert [:dholbert]

Updated

•

3 years ago

Summary: ResizeObserver API not behaving correctly inside iframes → ResizeObserver callback doesn't reliably fire, when observing an element in an iframe subdocument (with the observer registered in outer document)

Stefan Sechelmann

Comment 9

•

3 years ago

Fix is appreciated 👍 Just stumbled upon this in my own code base.

Boris Chiou [:boris]

Assignee

Comment 10

•

3 years ago

•

Edited

May take a look after I finish my current work. Looks like people need this.

Boris Chiou [:boris]

Assignee

Updated

•

3 years ago

Assignee: nobody → boris.chiou

Flags: needinfo?(boris.chiou)

Boris Chiou [:boris]

Assignee

Comment 11

•

3 years ago

Attached file Bug 1689099 - Schedule resize observers for the whole browsing context tree. — Details

It's possible to observe an element in the iframe while the
ResizeObserver object lives in the parent document. So we have to make
sure we also schedule the parent documents in DidDoReflow.

Phabricator Automation

Updated

•

3 years ago

Attachment #9231093 - Attachment description: Bug 1689099 - Schedule resize observers for in-process parent documents. → Bug 1689099 - Schedule resize observers for the whole browsing context tree.

Pulsebot

Comment 12

•

3 years ago

Pushed by bchiou@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1761d276b5f2
Schedule resize observers for the whole browsing context tree. r=emilio

Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)

Comment 13

•

3 years ago

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

Iulian Moraru

Comment 14

•

3 years ago

bugherder

https://hg.mozilla.org/mozilla-central/rev/1761d276b5f2

Status: NEW → RESOLVED

Closed: 3 years ago

status-firefox93: --- → fixed

Resolution: --- → FIXED

Target Milestone: --- → 93 Branch

Web Platform Test Sync Bot (Matrix: #interop:mozilla.org)

Comment 15

•

3 years ago

Upstream PR merged by moz-wptsync-bot

weihpeng

Comment 16

•

2 years ago

Test case mentioned above (https://jsfiddle.net/ujxkre85/) still doesn't work on version 102.3.0esr (64-bit).

You need to log in before you can comment on or make changes to this bug.