You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1. Key the scheduling state based on the {{Scheduler}} to prevent
leaking it across (potentially cross-origin) windows. This changes
the event loop's continuation state to be a small wrapper around a
map. The continuation state is propagated in the same way, but the
scheduler state is unique to the scheduler and not shared. In
practice there will only be one entry in this map (a task or
microtask can only have originated from one task), but the mechanism
is generic enough to support other use cases, implementations
can optimize this, and the key/value mapping hopefully makes the
isolation clear.
Alternatively, we could propagate only the state for the current
scheduler, but we don't always know the current scheduler, e.g. in
"queue a microtask", and this model is different enough from
AsyncContext and Chrome's "Task Attribution" that we'd need a
separate mechanism, which is a performance concern. The main
behavioral difference is how propagating is handled in the case of
A --> (B microtask) --> A. With this approach, the context is
preserved in the second call to A, which matches the synchronous
behavior of A --> calls B --> calls A.
2. Propagate the current scheduling state in "queue a microtask",
unless coming from JavaScript, in which case the propagation is
handled by the abstract job closure. Previously, the state would be
inherited only if it wasn't reset by another microtask or after the
postTask callback ran. This fixes the inconsistency, making directly
scheduled microtasks match microtasks originating from JavaScript.
0 commit comments