Could you please create a reproducing HTML and attach to this issue? That'll help our investigations.

After further investigation, I believe I have isolated the issue. The problem only occurs when the source of the off-screen iframe is under a different domain than the parent page. In my case, one included the www prefix on the domain while the other did not. As stated before, this problem does not occur if the iframe is visible, and it does not occur in IE, Edge, Firefox, or Safari, even if the iframe is off-screen. 

In the attached example, the problem will occur if the src of the child iframe is a different domain than the parent page. For my testing, I had the src of the iframe set to my domain without a www prefix but loaded the parent frame in the browser using the domain with the www prefix (both point to the same server location).

Deleted: 649849-parent.html 518 bytes

649849-parent.html 518 bytes View Download

Deleted: 649849-child.html 112 bytes

649849-child.html 112 bytes View Download

Thank you for providing more feedback. Adding requester "kojii@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

Thank you for creating the test case, this helps our investigation a lot.

Labeling so that the team can triage.

lfg@, could you take a look or re-triage?

@garland.pope, These are the steps I performed to reproduce the issue.

1) Downloaded both parent and child html files and placed them in same folder.
2)Opened the both html files with chrome version 53.0.2785.116 and opened the console for both web pages.
3) In the parent.html console, i found the following Error Message "Failed to load resource: the http://differentdomain.com/649849-child.html 
server responded with a status of 404 (Not Found)" 

4) In the child.html console, i found the following message "iFrame was resized"

5) whenever i manually resized the child.html, the count beside "iFrame was resized" is increasing

6)But when i click on the "Resize iFrame" button in parent.html, the count in the child.html console page is not increasing 

Is this is the issue you are mentioning???

Please Let Us know.

Thank You... 

Deleted: Parent.png 13.1 KB

	Parent.png 13.1 KB View Download

Deleted: Child.png 8.2 KB

	Child.png 8.2 KB View Download

+skyostil, is that related to the work to disable rendering on off-screen iframes?

Yes, it sounds like offscreen rendering pipeline throttling is the culprit here.

I would argue that this is working as intended: why should we tell an offscreen iframe about resizes given that nothing it will draw as a response will end up on the screen?

Note that as a workaround you can make the offscreen frame have a size of 0x0.

Tentatively marking WontFix. Please reopen if there's a reason to do something different here.

+kkaluri: 

The intention was for you to change "http://differentdomain.com" to a domain different from the one used to access the parent page but that does contain the child page. For me, they are both in the same physical folder, and both www.abcde.com and abcde.com point to that folder. I load the parent page from www.abcde.com while having the iframe loaded from abcde.com (without the www). The point is that the child page is coming from a different domain than the parent. There is no need to open the child page in its own browser window.

+skyostil:

Thanks for looking into this issue.

This behavior is different from every other major browser. Is it intended to be? Are there standards that suggest this is the correct behavior?

Here's my understanding of what's happening:

1) If the iframe is off screen but has the same domain as the main page, the resize event is triggered.
2) If the iframe is on screen (even sized to 1x1 with no border so that it's effectively invisible), the resize event is triggered, even if the domain is different.
3) But if the iframe is off screen AND has a different domain, the event is not triggered.

So you ARE triggering the event when the domain matches, even though nothing it will draw as a result will end up on the screen. And you ARE triggering the event if the size is 1x1, even though nothing it will draw as a result will end up on the screen. So the lack of a visible rendering change doesn't seem to be a justification for not triggering the event in this case, since it is triggered in other cases with no visible change. The size of the iframe IS changed, even if the user is not able to observe the change with his eyes. So it seems to me that the event should be triggered as it has always been in Chrome up to now.

BTW, I could not get the event to trigger when the iframe was sized to 0x0. It had to be at least 1x1, and its location had to be visible on the screen, not even further down on the page, accessible by scrolling. I actually had to scroll down to bring the empty space the iframe was occupying onto the screen to get the event to fire.

#11: That's right, we have some (somewhat arbitrary) exceptions to the throttling rules. These basically exist to avoid breaking existing sites that rely a specific behavior. Other browsers which do similar throttling (e.g., Safari, Firefox) have more or less the same failsafes, although Chrome is the only browser which completely suspends rendering-related events; the others mainly throttle them to a very low rate.

You can read more about this behavior here: https://github.com/WICG/interventions/issues/8

Re: 0x0 frames, sorry for not mentioning it earlier but I think that override might only be in Chrome M54+ at this point.