"Out of view" cross-origin iframes disable requestAnimationFrame/rendering pipeline

[toddreifsteck]

Firefox and Safari implement this. Chrome has an intent to implement.

[KenjiBaheux]

We later expanded to throttle the whole rendering pipeline: intent to ship

[toddreifsteck]

Updating title for this issue. When/if Edge implements this in the future, we are also likely to implement it by disabling the rendering pipeline.

Also.. re-using part of @cpeterso's comment in #9 regarding the Firefox bug that encompasses this issue and #9.
"I believe this was Firefox bug 1145439, which shipped in Firefox 40 (2015-08-11). The bug report mentions there may be regressions due to a priority inversion problem when throttled out-of-view iframes animate in-view content."

[KenjiBaheux]

Shipping in Chrome 51.

[brheenan]

A couple questions for the Chrome team:

• It looks like in Chrome Canary (54.0.2787.1) is allowing one RAF soon after page load before disabling the rendering pipeline (or at least RAF, which is all I'm measuring). Is this an intentional choice (and if so, why?) or is it a consequence of something else?
• The design doc mentions that 0x0 iframes are disabled, but display:none are not. Can you share the reasoning behind this?
• It looks like iframes clipped via CSS clip are still running. Is this intentional?

[KenjiBaheux]

cc/ @skyostil

[skyostil]

1. Yes, this was done to match the behavior of Safari.
2. The original reason for not throttling display:none/visibility:hidden frames was that Safari ran into compatibility issues while doing so. I suspect we might still be able to do this given the cross origin restriction, but so far haven't gotten around to it.
3. No, I think that's a bug: crbug.com/626362.

[brheenan]

Thanks!

[brheenan]

Edge intends to implement this.

[nolanlawson]

This is shipped to Insiders and slated for release in Edge 15.

[RByers]

Woot - our first modern intervention where I can add all 4 "shipped" labels 😄. @skyostil @domenic @nolanlawson, is there any spec work let to do, or is this enough to fully specify the behavior here? Once we're happy that this is properly specified and has appropriate web-platform-test coverage, we can close this issue.

[skyostil]

Great! \o/

I'm not sure how detailed we want the spec to be here. The current wording leaves a lot up to the implementation -- and the ones I've tried are all a little different; off the top of my head:

• Chrome and Safari fully stop rAF, while Firefox keeps it running at 1 Hz.
• Chrome only throttles cross origin frames while Safari and Firefox throttle all frames.
• Chrome throttles all of layout/paint/animations while Safari only throttles animations (as far as I can tell).
• Chrome doesn't quite deal correctly with 3D transformed frames (crbug.com/671348) -- I haven't tested the others.
• Chrome and Safari never throttle display:none frames, but do throttle child frames of display:none frames (haven't tried Firefox -- test here: https://jsfiddle.net/ohpkjn9p/2)

Other than the 3D bug, all of these are still in line with the spec. Maybe that's fine, but it will make writing a web-platform-test pretty difficult.

[domenic]

Oh great, my comments were going to be along the lines of "is everyone actually compatible? If so maybe we should tighten the spec." But @skyostil did all the research to show that nobody is really compatible.

If we want, we could try to converge everyone on the same behavior, and then tighten the spec accordingly. But if we think the current landscape is fine, then the spec is fine too, IMO. It's one of those predictability vs. user agent freedom tradeoffs, I guess.

[jlkalberer]

I've also noticed with FF that it stops throttling when the iframe gets close to the viewport -- not when it's actually in the iframe.

This only happens after the user has scrolled. If you refresh the page and the iframe is 1px outside the viewport it works as expected.

[domenic]

This is currently in the HTML Standard. It first made it in as whatwg/html#665, with the verbiage

If there are a nested browsing contexts B that the user agent believes would not benefit from having their rendering updated at this time, then remove from docs all Document objects whose browsing context is in B.

NOTE: as with top-level browsing contexts, a variety of factors can influence whether it is profitable for a browser to update the rendering of nested browsing contexts. For example, a user agent might wish to spend less resources rendering third-party content, especially if it is not currently visible to the user or if resources are constrained. In such cases, the browser could decide to update the rendering for such content infrequently or never.

In whatwg/html#3923, we split up the reasons for skipping rendering, in order to better specify their impact on the Paint Timing API. The current text which specifies this change is

Rendering opportunities: Remove from docs all Document objects whose browsing context do not have a rendering opportunity.

A browsing context has a rendering opportunity if the user agent is currently able to present the contents of the browsing context to the user, accounting for hardware refresh rate constraints and user agent throttling for performance reasons, but considering content presentable even if it's outside the viewport.

[...]

This specification does not mandate any particular model for selecting rendering opportunities. But for example, if the browser is attempting to achieve a 60Hz refresh rate, then rendering opportunities occur at a maximum of every 60th of a second (about 16.7ms). If the browser finds that a browsing context is not able to sustain this rate, it might drop to a more sustainable 30 rendering opportunities per second for that browsing context, rather than occasionally dropping frames. Similarly, if a browsing context is not visible, the user agent might decide to drop that page to a much slower 4 rendering opportunities per second, or even less.

(emphasis mine)

As such, I'll close out this issue, as part of our larger project to archive this repository (see #72). Please feel free to have discuss anything related on the HTML Standard repository, at whatwg/html!