Closed toddreifsteck closed 2 years ago
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/
@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.
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.
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.)
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/
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 https://github.com/WICG/interventions/issues/9#issuecomment-228354720, or mute the thread https://github.com/notifications/unsubscribe/AGD3Ctjse6lW0gbCntAohveSX7MzlmWqks5qO-ROgaJpZM4HcR_4 .
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
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.
Update: this is now shipping in Chrome M53.
Edge intends to implement this.
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()
.
(As noted in https://github.com/WICG/interventions/pull/72, we intend to archive this repository and are thus triaging and resolving all open issues)
I filed https://github.com/whatwg/html/issues/7941 for further standardization and linked to this issue for context.
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.