diff --git a/source b/source index 6912026b81c..87bf307ea2f 100644 --- a/source +++ b/source @@ -93936,7 +93936,7 @@ import "https://example.com/foo/../module2.mjs"; -
If all of the following are true
Objects that implement the WindowOrWorkerGlobalScope
mixin have a map of active timers, which is a map, initially empty. Each
- key in this map is identified by a number, which must be unique
- within the list for the lifetime of the object that implements the
- WindowOrWorkerGlobalScope
mixin, and each value is a
- DOMHighResTimeStamp
, representing the expiry time for that timer.
Objects that implement the WindowOrWorkerGlobalScope
mixin have a map of
+ active timers, which is a map, initially empty. Each key in this map is an identifier for a timer, and each value is a DOMHighResTimeStamp
, representing the expiry time for that
+ timer.
For entries put in the map of active timers by the timer
+ initialization steps, i.e., by setTimeout()
and setInterval()
, the keys are numbers. For other specifications
+ that use the run steps after a timeout algorithm, the identifier is a unique
+ non-numeric value. Only the numeric-keyed timers are affected by clearTimeout()
and clearInterval()
, but all timers contribute to idle deadline computation, and are cleared when the
+ relevant global is destroyed.
If previousId was given, let id be previousId; otherwise, let id be an implementation-defined integer that is greater - than zero that will identify the timeout to be set by this call in global's map - of active timers.
If the surrounding agent's event
@@ -96580,50 +96589,19 @@ enum DOMParserSupportedType {
Set task's timer nesting level to nesting level. Let startTime be the current high resolution time. Set global's map of active
- timers[id] to startTime plus timeout. Let completionStep be an algorithm step which queues a global task on the timer task source given
+ global to run task. Run the following steps in parallel: If global is a Otherwise, global is a Wait until any invocations of this algorithm that had the same global, that
- started before this one, and whose timeout is equal to or less than this one's,
- have completed. Optionally, wait a further implementation-defined length of time. This is intended to allow user agents to pad timeouts as needed to optimize
- the power usage of the device. For example, some processors have a low-power mode where the
- granularity of timers is reduced; on such platforms, user agents can slow timers down to fit
- this schedule instead of requiring the processor to use the more accurate mode with its
- associated higher power usage. Run steps after a timeout given global, " Queue a global task on the timer task source given
- global to run task. Once the task has been processed, if repeat is false, it is safe
- to remove the entry for id from the map of active timers (there is no
- way for the entry's existence to be detected past this point, so it does not technically
- matter one way or the other). Once the task has been processed, if repeat is false, it is safe to
+ remove the entry for id from the map of active timers (there is no way
+ for the entry's existence to be detected past this point, so it does not technically matter one
+ way or the other). Return id.
-
+ Window
object, wait until global's associated Document
has been fully
- active for a further timeout milliseconds (not necessarily
- consecutively).WorkerGlobalScope
object; wait
- until timeout milliseconds have passed with the worker not suspended (not
- necessarily consecutively).setTimeout/setInterval
", timeout, completionStep, and
+ id.
To run steps after a timeout, given a WindowOrWorkerGlobalScope
+ global, a string orderingIdentifier, a number milliseconds, a
+ set of steps completionSteps, and an optional value timerKey:
Assert: if timerKey is given, then the caller of this algorithm is the + timer initialization steps. (Other specifications must not pass + timerKey.)
If timerKey is not given, then set it to a new unique non-numeric + value.
Let startTime be the current high resolution time.
Set global's map of active + timers[timerKey] to startTime plus + milliseconds.
Run the following steps in parallel:
+ +If global is a Window
object, wait until global's associated Document
has been fully
+ active for a further milliseconds milliseconds (not necessarily
+ consecutively).
Otherwise, global is a WorkerGlobalScope
object; wait until
+ milliseconds milliseconds have passed with the worker not suspended (not
+ necessarily consecutively).
Wait until any invocations of this algorithm that had the same global and + orderingIdentifier, that started before this one, and whose milliseconds + is equal to or less than this one's, have completed.
Optionally, wait a further implementation-defined length of time.
+ +This is intended to allow user agents to pad timeouts as needed to optimize + the power usage of the device. For example, some processors have a low-power mode where the + granularity of timers is reduced; on such platforms, user agents can slow timers down to fit + this schedule instead of requiring the processor to use the more accurate mode with its + associated higher power usage.
+Perform completionSteps.
Run steps after a timeout is meant to be used by other
+ specifications that want to execute developer-supplied code after a developer-supplied timeout,
+ in a similar manner to setTimeout()
. (Note, however, it does
+ not have the nesting and clamping behavior of setTimeout()
.)
+ Such specifications can choose an orderingIdentifier to ensure ordering within their
+ specification's timeouts, while not constraining ordering with respect to other specification's
+ timeouts.