Editorial: Use the HTML spec's timers infrastructure for timeout

[andreubotella]

In whatwg/html#7349, the HTML spec factored out part of the infrastructure for setTimeout() into a "run steps after a timeout" algorithm for use by other specs. This change updates requestIdleCallback() to use that algorithm when the timeout property is present and positive.

---

Preview | Diff

[w3cbot]

andreubotella marked as non substantive for IPR from ash-nazg.

[yoavweiss]

Thanks for aligning this with HTML spec changes.

@noamr - can you review?

[andreubotella]

Come to think about it, this change is not in fact editorial, since the "run steps after a timeout" algorithm adds an entry to the map of active timers, which in turn affects the idle deadline. It might still be worth making the change, though.

[noamr]

LGTM

[yoavweiss]

@andreubotella - For some reason, we never clicked the green button and merged this.. Any reason I shouldn't? :)

[mmocny]

Issue triage: @shaseley can you check if this still makes sense to land, please? Seems it was meant to be landed a few years back.

[shaseley]

As @andreubotella mentioned, this actually changes behavior in an observable way since the idle deadline computation is based on queued timers. But looking at Chrome's implementation, we do take into account idle task timeouts in the deadline computation, albeit with a few differences [1] (which ought to be fixed). Looks like FF also takes pending idle timeouts into account.

So I think this PR actually matches existing behavior, but we might not want the timer associated with an idle task that runs while idle (didn't time out yet) to be considered. Since the timer isn't removed from the map when its corresponding idle task runs, it counts towards the deadline:

setTimeout(() => {
  // If this ran while idle with no frame expected, timeRemaining should be ~50, not ~10.
  // You can see the difference in Chrome and FF if changing the timeout to 10000.
  requestIdleCallback(d => {
    console.log('Time remaining: ' + d.timeRemaining());
  }, {timeout: 10});
}, 1000);

We can get around that by removing the timer from the map before executing the callback.

Note: Chrome's does not currently remove the timer from the map, it does that after the callback runs (it's also static and fixed before running the callback, so it would take some work to fix this). It looks like FF matches Chrome's behavior here as well, as we have the same behavior with that snippet. cc @smaug---- for thoughts on the FF side.

[1] Chrome doesn't support dynamically added timers, and for some reason, we only take the pending timers into account for "long idle periods", i.e. when we aren't expecting a frame. This might predate some of the spec work that integrated the deadline computation into HTML a few years ago.