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

Open
toddreifsteck opened this Issue Feb 17, 2016 · 11 comments

Projects

None yet

7 participants

@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
Collaborator

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.

@ojanvafai ojanvafai added the Chrome-P1 label Apr 22, 2016
@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
Collaborator

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
skyostil commented Sep 6, 2016

Update: this is now shipping in Chrome M53.

@brheenan
brheenan commented Nov 3, 2016

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().

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment