Non-cancelled setTimeouts would lead to idle deadlines in the past
#7376
Comments
|
Good catch, thanks. Would you like to submit a PR removing the map entry? |
andreubotella
pushed a commit
to andreubotella/html
that referenced
this issue
Nov 29, 2021
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 whatwg#7376.
3 tasks
domenic
pushed a commit
that referenced
this issue
Nov 30, 2021
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.
mfreed7
pushed a commit
to mfreed7/html
that referenced
this issue
Jun 3, 2022
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 whatwg#7376.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Before #7166, there was no way to observe whether a
setTimeout()timer's ID is in the list of active timers after the timer callback has been run, and so the timer task does not remove that ID from the list. However, that PR made the list of active timers into a map of active timers that is used to determine the idle deadline to use for therequestIdleCallback()API, and such timer ID's would result in the computed deadline being in the past if anysetTimeout()timer was started and its callback was run.The text was updated successfully, but these errors were encountered: