1357842 - Throttle timeouts in foreground cross-origin iframes that the user hasn't interacted with to 30fps

Status: NEW

(Core :: DOM: Core & HTML, enhancement, P3)

Description

[(no longer active)]

Safari has started doing this: https://trac.webkit.org/changeset/215116/webkit

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to :Ehsan Akhgari (super long backlog, slow to respond) from comment #0)
> Safari has started doing this:
> https://trac.webkit.org/changeset/215116/webkit

Is this something blocking our Quantum DOM stuff?

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

Not really. This is rather separate thing from other Quantum DOM, but as such could indeed be considered as part of Quantum DOM.

This may make the code a bit hairy once we have also the TP throttling.

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

The thing that is interesting to me about what safari is doing is that they are throttling *foreground* timers.  AFAIK browsers have not successfully done this before.  Just adding our timer yielding stuff with the ThrottledEventQueue hit a bit of web compat.  If they can get away with throttling all cross-origin iframes in the foreground we can probably throttle all TP scripts in the foreground as well.

I wonder if they are doing anything to mitigate the loading spinner while the cross-origin iframes are delayed.  I think thats why we were experimenting with only throttling TP scripts after load.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

We already have plans to throttle foreground TP timers.
If one can throttle TP timers in background, throttling them in foreground should work too, and it is easier to notice regressions when throttling happens in foreground.

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information