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

NEW
Unassigned

Status

()

Core
DOM
P2
normal
a year ago
a year ago

People

(Reporter: Ehsan, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

a year ago
Safari has started doing this: https://trac.webkit.org/changeset/215116/webkit
(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?
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.
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.
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.
Priority: -- → P2
You need to log in before you can comment on or make changes to this bug.