Remove a setTimeout's entry in the map of active timers after it runs

[andreubotella]

It used to be unobservable whether a non-repeating timer that had already run its callback had an entry in the list of active timers or not, and so those entries were never removed from the list. However, calculation of the idle deadline, meaning that if a timer expires and is never cancelled, the deadline will be in the past.

This change avoids this case by removing non-repeating timers from the map of active timers after their callback runs.

Closes #7376.

• At least two implementers are interested (and none opposed):
  • Chrome and Firefox implement it.
  • Safari doesn't shit requestIdleCallback() yet.
• Tests are written and can be reviewed and commented upon at:
  • Test that the idle deadline after an expired timer is non-negative web-platform-tests/wpt#31853
• Implementation bugs are filed:
  • Safari: …

(See WHATWG Working Mode: Changes for more details.)

---

/timers-and-user-prompts.html ( diff )

[andreubotella]

Now that I think about it, if timerKey in "run steps after a timeout" is not a number, it would also have to be removed from the map after the wait. I'm assuming that's fine, concurrency-wise.

[annevk]

I think this works, but I also think the current setup is broken in other ways. It works for AbortSignal now, but if we wanted to add timeout support to AbortController so it could also be removed again, there's no way to do that currently. That would require handing the key back to the calling algorithm and checking if the key is still in the map before running completionSteps.

[domenic]

This seems good to me. Regarding @annevk's comment, it doesn't feel like the current setup is broken, but instead that we'd have to add more complications to it if we want to allow more complicated caller patterns in the future?

[andreubotella]

This PR wasn't editorial, and I was planning on writing tests for it (and seeing if any browser engine bugs needed to be filed) tomorrow.

[domenic]

Oh, I'm so sorry about that! I was thinking of it as a bugfix to bd63843, but I agree that probably this case wasn't covered in the tests for that commit, so it would have been better to wait.

[annevk]

@domenic yeah I guess that can work. I was thinking that might allow consolidation of the removal after the completion steps have run. I guess as long as we don't have too many callers of the algorithm it doesn't really matter.

[andreubotella]

Tests are at web-platform-tests/wpt#31853