Able to reproduce the issue on Windows-10 using chrome latest stable M52-52.0.2743.116. Observed that the third and fifth iframe will log a resize event under console.

Tested the same on earlier versions of chrome M35-35.0.1849.0 and observed different behavior. Attaching screen-shot for confirmation.

rassinator@ - Could you please confirm is this is the expected behavior of the issue from the attached snapshot.

Deleted: Capture.PNG 841 KB

	Capture.PNG 841 KB View Download

brajkumar@chromium.org - That snapshot is the expected behavior

Updated the gist to add a sixth-iframe. This iframe is a 10px, 100% width iframe that would normally be visible except for its -50px margin-top, which effectively puts it above the browser view. Again, when all the domains are the same the sixth-iframe resize gets logged, but if they're different then it is not logged.

Thank you for providing more feedback. Adding requester "brajkumar@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I'm attaching the files I got from the repro for posterity since the gists may change.

Interesting bug! This is to do with resize events in iframe windows. 'resize' is part of CSSOMView, FWIW.

The next step is to debug this and work out how negative margins and cross-origin interact to stop an event being dispatched. Lots of moving parts. tkent, would you be able to take a look at this?

The iframe's contents' document client{Width,Height} properties, etc. are changing so we probably should be firing resize events. We do when same origin. When cross-origin, we don't when one of the child iframes is pushed off the screen by a negative margin. (I reproduced this in Chrome Linux 55.0.2883.75 (Official Build) (64-bit) logs 2-3-4-5 but not 6th.)

FF 50.0.2 logs 2, 3, 6 in different orders. I guess Firefox doesn't resize *hidden* iframes (but it does opacity 0 or height 0 ones.) We probably shouldn't rely on studying Firefox too closely in this case.

brajkumar, let's use "expected behavior" to describe what the product should be doing. It gets confusing when you talk about the expected behavior of the bug repro; it makes it sound like the buggy behavior is the desired behavior.

Deleted: first-iframe.html 852 bytes

first-iframe.html 852 bytes View Download

Deleted: iframe-holder.html 98 bytes

iframe-holder.html 98 bytes View Download

This probably has to with throttling rendering in offscreen or hidden cross-origin frames. Does this test case work in Safari 10?

A lot of browsers are experimenting with behavior here. Is there a site that's broken because of this? 

Next step here is to see what latest version of each browser does and start a discussion at https://github.com/WICG/interventions/issues/8 about what behavior we should all try to converge on.

I'm a little confused. If the target frame is cross-origin, then you won't be able to observe the resize event (i.e., contentWindow.addEventListener(...)) from the parent frame. Is the bug here that we're treating about:blank as cross origin?

I suspect it's not a cross origin thing about:blank thing. If you look at the properties on the frames in the repro, it's experimenting with making them "invisible" various ways (negative margin, 0 height, etc.) and observing that different combinations of these suppress different events in different browsers.

In Chrome's case origins also come into play.

High-level, something's wrong here because FF and Chrome behave quite differently. It would be good to see what other browsers do.

This is just frame throttling, we dispatch resize events inside the same system that runs rAf, which is throttled for off screen cross origin iframes. The event might even be queued there if you force a layout, it'll just not be dispatched until the next frame.

This is a frame throttling system design question.

Right. I'd be inclined to say this is by design, since you won't be able to do that many useful things with the resize event anyway because we'll be throttling painting while the frame is offscreen.

Unlike Chrome, FF doesn't completely block offscreen rAF but instead ticks it at 1 Hz. That might explain why you're seeing the resize events there.

Forgot to task: is there a (non-synthetic) example page that is broken by this?

Reporter@

Could you please let us know your observations on Comment#13.

Thank you.

@ dominicc: Gentle ping, Can we have an update on this issue as requested in comment#13. Issue is tagged with bisect label from a long period.

Thanks.!

There is no longer an example page because the code changed to avoid this issue. We have a javascript widget that can either be injected directly into the DOM or used in an iframe. This widget listens to an inner iframe being resized so it can adjust accordingly. This allows the widget to not need to poll its dimensions periodically to adjust itself. Originally only the width was needed, so the iframe was given a 0 height.

Cleaning up sheriffbot label "Needs-Review" label as a part of modified "Needs-Feedback" sheriffbot rule. [ref bug for cleanup 684919]

There is no valid updates happened in the last few months, closing the issue. Feel free to reopen if needed.