"Out of view" cross-origin iframes align/clamp setTimeout/setInterval to 1 second

[toddreifsteck]

My research leads me to believe that Firefox implements this as of ~June 2015, but no other browser does at this time. Chrome was researching it, I believe.

[cpeterso]

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.

The Chrome team shared a design doc for "Throttling Blink’s rendering pipeline for hidden content":

https://docs.google.com/document/d/1Dd4qi1b_iX-OCZpelvXxizjq6dDJ76XNtk37SZEoTYQ/

[toddreifsteck]

@cpeterso , I think the Chrome bug is #8 . There is currently no mention of throttling setTimeout/setInterval within the shared spec as far as I can see.

I believe that Firefox bug 1145439 encompasses both #8 and this issue.

[KenjiBaheux]

Yes, what we currently have is closer to #8.

That being said, throttling timers for out-of-view cross origin iframes is appealing.
For instance, some popular animation framework like createjs defaults to setTimeout (see TIMING MODES section) to run their animation loops.

[skyostil]

Safari does this (as of iOS 9 I believe) for all frames, not just cross-origin ones. We are now planning to do the same in Chrome. Safari additionally uses a random phase offset for different processes to avoid a thundering herd problem. I'm not sure yet whether we want to do that too.

Here's a design doc: https://docs.google.com/document/d/1Xa8sd2M_Eh6hGSWeKTy_akzKdxcVZjCk4PQMqV8yXXw/edit#heading=h.1wwonxnzf5ei

(Note that throttling network tasks is out of scope for now even though they are mentioned in the design doc.)

[skyostil]

The one open issue from my point of view is whether we should throttle all frames or just cross-origin ones. Throttling everything would be more consistent, but throttling cross-origin perhaps more precisely solves the main problem of providing performance isolation between first and third parties.

I believe @ojanvafai was advocating for cross-origin-only. I think I slightly prefer throttling everything just to keep things consistent, but could be convinced for just cross-origin too. What do others think?

Here's a quick test page: http://jsfiddle.net/3L9c9uyc/3/embedded/result/

[KenjiBaheux]

I think we should start with just cross origin iframes and perhaps have a
UMA to tell us how much more opportunity there would be with doing so
accross the board.

On Fri, Jun 24, 2016, 11:06 PM Sami Kyöstilä notifications@github.com
wrote:

The one open issue from my point of view is whether we should throttle all
frames or just cross-origin ones. Throttling everything would be more
consistent, but throttling cross-origin perhaps more precisely solves the
main problem of providing performance isolation between first and third
parties.

I believe @ojanvafai https://github.com/ojanvafai was advocating for
cross-origin-only. I think I slightly prefer throttling everything just to
keep things consistent, but could be convinced for just cross-origin too.
What do others think?

Here's a quick test page: http://jsfiddle.net/3L9c9uyc/3/embedded/result/

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#9 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AGD3Ctjse6lW0gbCntAohveSX7MzlmWqks5qO-ROgaJpZM4HcR_4
.

[brheenan]

On Edge, we're looking at starting with cross origin, as there's less risk of breaking user-benefiting content. Though it's good to know that Safari is doing this for all iframes

[skyostil]

Starting with cross origin frames sounds good to me. I've just sent an intent to implement: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/_Lhz8THHk2Q.

[skyostil]

Update: this is now shipping in Chrome M53.

[brheenan]

Edge intends to implement this.

[nolanlawson]

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

For the record, Azure Portal experienced a regression in Chrome 55 related to throttling of postMessage(). They filed an issue on Chrome; looks like it will be fixed in M57. They haven't reported any issues with Edge's implementation, since we didn't throttle postMessage().

[johannhof]

(As noted in #72, we intend to archive this repository and are thus triaging and resolving all open issues)

I filed whatwg/html#7941 for further standardization and linked to this issue for context.