search

WICG / interventions

A place for browsers and web developers to collaborate on user agent interventions.
Other
177 stars 28 forks source link

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

Closed toddreifsteck closed 2 years ago

toddreifsteck commented 8 years ago

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

KenjiBaheux commented 8 years ago

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

toddreifsteck commented 8 years ago

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 commented 8 years ago

Shipping in Chrome 51.

brheenan commented 8 years ago

A couple questions for the Chrome team:

KenjiBaheux commented 8 years ago

cc/ @skyostil

skyostil commented 8 years ago
  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 commented 8 years ago

Thanks!

brheenan commented 7 years ago

Edge intends to implement this.

nolanlawson commented 7 years ago

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

RByers commented 7 years ago

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 commented 7 years ago

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:

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 commented 7 years ago

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 commented 7 years ago

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 commented 2 years ago

This is currently in the HTML Standard. It first made it in as https://github.com/whatwg/html/pull/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 https://github.com/whatwg/html/pull/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!