diff --git a/source b/source index 5af18751cc0..5c5d0427c63 100644 --- a/source +++ b/source @@ -77492,11 +77492,6 @@ console.assert(iframeWindow.frameElement === null); any other group. Each such group is a unit of related similar-origin browsing contexts.

-

There is also at most one event loop per unit of related - similar-origin browsing contexts (though several units of related similar-origin browsing contexts can - have a shared event loop).

- @@ -78978,13 +78973,9 @@ interface BarProp {
The responsible event loop
-
- -

Return the event loop that is associated with the unit of related - similar-origin browsing contexts to which window's browsing - context belongs.

- -
+

Return the event loop associated with the agent whose set of + realms contains window's relevant + Realm.

The responsible document
@@ -88680,7 +88671,7 @@ import "https://example.com/foo/../module2.mjs";

JavaScript is expected to define agents in more detail; in particular that they hold a set of realms: tc39/ecma262 issue #882.

+ href="https://github.com/tc39/ecma262/issues/1357">tc39/ecma262 issue #1357.

Conceptually, the agent concept is an architecture-independent, idealized "thread" in which JavaScript code runs. Such code can involve multiple globals/PromiseRejectionEventInit : EventInit {

To coordinate events, user interaction, scripts, rendering, networking, and so forth, user agents must use event loops as - described in this section. There are two kinds of event loops: those for browsing contexts, and those for workers.

+ described in this section. Each agent has one event loop. -

There must be at least one browsing context event loop per user - agent, and at most one per unit of related similar-origin browsing contexts.

- -

When there is more than one event loop for a unit of related - browsing contexts, complications arise when a browsing context in that group - is navigated such that it switches from one unit of related - similar-origin browsing contexts to another. This specification does not currently describe - how to handle these complications.

- -

A browsing context event loop always has at least one browsing - context. If such an event loop's browsing - contexts all go away, then the event loop goes away as well. A browsing - context always has an event loop coordinating its activities.

- -

Worker event loops are simpler: each worker has one - event loop, and the worker processing model - manages the event loop's lifetime.

+

This specification does not currently describe how to handle the complications + arising from navigating between similar-origin window agents.

@@ -89187,18 +89162,19 @@ dictionary PromiseRejectionEventInit : EventInit { -

Each task in a browsing context event - loop is associated with a Document; if the task was queued in the context of - an element, then it is the element's node document; if the task was queued in the context - of a browsing context, then it is the browsing context's active - document at the time the task was queued; if the task was queued by or for a script then the document is the responsible document - specified by the script's settings object.

+

Each task in an event loop for a + similar-origin window agent is associated with a Document; if the task + was queued in the context of an element, then it is the element's node document; if + the task was queued in the context of a browsing context, then it is the + browsing context's active document at the time the task was queued; if + the task was queued by or for a script then the document is + the responsible document specified by the script's settings object.

A task is intended for a specific event loop: the event loop that is handling tasks for the task's associated Document or worker.

+

When a user agent is to queue a task, it must add the given task to one of the task queues of the relevant event @@ -89206,7 +89182,7 @@ dictionary PromiseRejectionEventInit : EventInit {

Each task is defined as coming from a specific task source. All the tasks from one particular task source and - destined to a particular event loop (e.g. the callbacks generated by timers of a + destined to a particular event loop (e.g., the callbacks generated by timers of a Document, the events fired for mouse movements over that Document, the tasks queued for the parser of that Document) must always be added to the same task queue, but tasks from different PromiseRejectionEventInit : EventInit {

  • Let oldestTask be the oldest task on one of the event loop's task queues, if any, - ignoring, in the case of a browsing context event loop, tasks whose - associated Documents are not fully active. The user agent may pick any - task queue. If there is no task to select, then jump to the microtasks step - below.

    • + ignoring, in the case of a similar-origin window agent event loop, + tasks whose associated Documents are not fully active. The user agent + may pick any task queue. If there is no task to select, then jump to the + microtasks step below.

  • Report the duration of time during which the user agent does not execute this loop by @@ -89296,9 +89272,8 @@ dictionary PromiseRejectionEventInit : EventInit {

  • -

    Update the rendering: If this event loop is a - browsing context event loop (as opposed to a worker event loop), then run the following substeps.

    +

    Update the rendering: if this event loop is for a + similar-origin window agent, then:

    1. @@ -89422,14 +89397,13 @@ dictionary PromiseRejectionEventInit : EventInit {
    • -

  • If this is a browsing context event loop (as opposed to a worker event loop), and there are no tasks in the event loop's task queues, and the event loop's microtask queue is - empty, and none of the browsing contexts have a - rendering opportunity, then for each browsing context, run the steps in - the start an idle period algorithm, passing the Window associated with - that browsing context.

    • +

  • If this is an event loop for a similar-origin window agent, and + there are no tasks in the event loop's task queues, and the event loop's microtask + queue is empty, and none of the browsing contexts + have a rendering opportunity, then for each browsing context, run the + steps in the start an idle period algorithm, passing the Window + associated with that browsing context.

  • Report the duration of the update the rendering step by performing the @@ -89450,14 +89424,16 @@ dictionary PromiseRejectionEventInit : EventInit {

  • -

    If this is a worker event loop (i.e., one running for - a WorkerGlobalScope):

    +

    If this is an event loop that is not for a similar-origin window + agent or worklet agent (e.g., one for a dedicated worker + agent):

    1. If this is a supported DedicatedWorkerGlobalScope and the user agent believes that it would benefit from having its rendering updated at this time, then:

      +

      1. Let now be the current high resolution time. SharedWorkerGlobalScope : WorkerGlobalScope {

        The event loop

        + +

        Each WorkerGlobalScope object has a distinct event loop, separate from those used by units of related similar-origin browsing contexts. This event loop has no associated