1. 8 Web application APIs
    1. 8.1 Scripting
      1. 8.1.1 Introduction
      2. 8.1.2 Agents and agent clusters
        1. 8.1.2.1 Integration with the JavaScript agent formalism
        2. 8.1.2.2 Integration with the JavaScript agent cluster formalism
      3. 8.1.3 Realms and their counterparts
        1. 8.1.3.1 Environments
        2. 8.1.3.2 Environment settings objects
        3. 8.1.3.3 Realms, settings objects, and global objects
          1. 8.1.3.3.1 Entry
          2. 8.1.3.3.2 Incumbent
          3. 8.1.3.3.3 Current
          4. 8.1.3.3.4 Relevant
        4. 8.1.3.4 Enabling and disabling scripting
        5. 8.1.3.5 Secure contexts
      4. 8.1.4 Script processing model
        1. 8.1.4.1 Scripts
        2. 8.1.4.2 Fetching scripts
        3. 8.1.4.3 Creating scripts
        4. 8.1.4.4 Calling scripts
        5. 8.1.4.5 Killing scripts
        6. 8.1.4.6 Runtime script errors
        7. 8.1.4.7 Unhandled promise rejections
        8. 8.1.4.8 Import map parse results
      5. 8.1.5 Module specifier resolution
        1. 8.1.5.1 The resolution algorithm
        2. 8.1.5.2 Import maps
        3. 8.1.5.3 Import map processing model
      6. 8.1.6 JavaScript specification host hooks
        1. 8.1.6.1 HostEnsureCanAddPrivateElement(O)
        2. 8.1.6.2 HostEnsureCanCompileStrings(realm, parameterStrings, bodyString, codeString, compilationType, parameterArgs, bodyArg)
        3. 8.1.6.3 HostGetCodeForEval(argument)
        4. 8.1.6.4 HostPromiseRejectionTracker(promise, operation)
        5. 8.1.6.5 HostSystemUTCEpochNanoseconds(global)
        6. 8.1.6.6 Job-related host hooks
          1. 8.1.6.6.1 HostCallJobCallback(callback, V, argumentsList)
          2. 8.1.6.6.2 HostEnqueueFinalizationRegistryCleanupJob(finalizationRegistry)
          3. 8.1.6.6.3 HostEnqueueGenericJob(job, realm)
          4. 8.1.6.6.4 HostEnqueuePromiseJob(job, realm)
          5. 8.1.6.6.5 HostEnqueueTimeoutJob(job, realm, milliseconds)
          6. 8.1.6.6.6 HostMakeJobCallback(callable)
        7. 8.1.6.7 Module-related host hooks
          1. 8.1.6.7.1 HostGetImportMetaProperties(moduleRecord)
          2. 8.1.6.7.2 HostGetSupportedImportAttributes()
          3. 8.1.6.7.3 HostLoadImportedModule(referrer, moduleRequest, loadState, payload)
      7. 8.1.7 Event loops
        1. 8.1.7.1 Definitions
        2. 8.1.7.2 Queuing tasks
        3. 8.1.7.3 Processing model
        4. 8.1.7.4 Generic task sources
        5. 8.1.7.5 Dealing with the event loop from other specifications
      8. 8.1.8 Events
        1. 8.1.8.1 Event handlers
        2. 8.1.8.2 Event handlers on elements, Document objects, and Window objects
          1. 8.1.8.2.1 IDL definitions
        3. 8.1.8.3 Event firing
    2. 8.2 The WindowOrWorkerGlobalScope mixin
    3. 8.3 Base64 utility methods

8 Web application APIs

8.1 Scripting

8.1.1 Introduction

Various mechanisms can cause author-provided executable code to run in the context of a document. These mechanisms include, but are probably not limited to:

8.1.2 Agents and agent clusters

8.1.2.1 Integration with the JavaScript agent formalism

JavaScript defines the concept of an agent. This section gives the mapping of that language-level concept on to the web platform.

Conceptually, the agent concept is an architecture-independent, idealized "thread" in which JavaScript code runs. Such code can involve multiple globals/realms that can synchronously access each other, and thus needs to run in a single execution thread.

Two Window objects having the same agent does not indicate they can directly access all objects created in each other's realms. They would have to be same origin-domain; see IsPlatformObjectSameOrigin.

The following types of agents exist on the web platform:

Similar-origin window agent

Contains various Window objects which can potentially reach each other, either directly or by using document.domain.

If the encompassing agent cluster's is origin-keyed is true, then all the Window objects will be same origin, can reach each other directly, and document.domain will no-op.

Two Window objects that are same origin can be in different similar-origin window agents, for instance if they are each in their own browsing context group.

Dedicated worker agent

Contains a single DedicatedWorkerGlobalScope.

Shared worker agent

Contains a single SharedWorkerGlobalScope.

Service worker agent

Contains a single ServiceWorkerGlobalScope.

Worklet agent

Contains a single WorkletGlobalScope object.

Although a given worklet can have multiple realms, each such realm needs its own agent, as each realm can be executing code independently and at the same time as the others.

Only shared and dedicated worker agents allow the use of JavaScript Atomics APIs to potentially block.

To create an agent, given a boolean canBlock:

  1. Let signifier be a new unique internal value.

  2. Let candidateExecution be a new candidate execution.

  3. Let agent be a new agent whose [[CanBlock]] is canBlock, [[Signifier]] is signifier, [[CandidateExecution]] is candidateExecution, and [[IsLockFree1]], [[IsLockFree2]], and [[LittleEndian]] are set at the implementation's discretion.

  4. Set agent's event loop to a new event loop.

  5. Return agent.

For a realm realm, the agent whose [[Signifier]] is realm.[[AgentSignifier]] is the realm's agent.

The relevant agent for a platform object platformObject is platformObject's relevant realm's agent.

The agent equivalent of the current realm is the surrounding agent.

8.1.2.2 Integration with the JavaScript agent cluster formalism

JavaScript also defines the concept of an agent cluster, which this standard maps to the web platform by placing agents appropriately when they are created using the obtain a similar-origin window agent or obtain a worker/worklet agent algorithms.

The agent cluster concept is crucial for defining the JavaScript memory model, and in particular among which agents the backing data of SharedArrayBuffer objects can be shared.

Conceptually, the agent cluster concept is an architecture-independent, idealized "process boundary" that groups together multiple "threads" (agents). The agent clusters defined by the specification are generally more restrictive than the actual process boundaries implemented in user agents. By enforcing these idealized divisions at the specification level, we ensure that web developers see interoperable behavior with regard to shared memory, even in the face of varying and changing user agent process models.

An agent cluster has an associated cross-origin isolation mode, which is a cross-origin isolation mode. It is initially "none".

An agent cluster has an associated is origin-keyed (a boolean), which is initially false.


The following defines the allocation of the agent clusters of similar-origin window agents.

An agent cluster key is a site or tuple origin. Without web developer action to achieve origin-keyed agent clusters, it will be a site.

An equivalent formulation is that an agent cluster key can be a scheme-and-host or an origin.

To obtain a similar-origin window agent, given an origin origin, a browsing context group group, and a boolean requestsOAC, run these steps:

  1. Let site be the result of obtaining a site with origin.

  2. Let key be site.

  3. If group's cross-origin isolation mode is not "none", then set key to origin.

  4. Otherwise, if group's historical agent cluster key map[origin] exists, then set key to group's historical agent cluster key map[origin].

  5. Otherwise:

    1. If requestsOAC is true, then set key to origin.

    2. Set group's historical agent cluster key map[origin] to key.

  6. If group's agent cluster map[key] does not exist, then:

    1. Let agentCluster be a new agent cluster.

    2. Set agentCluster's cross-origin isolation mode to group's cross-origin isolation mode.

    3. If key is an origin:

      1. Assert: key is origin.

      2. Set agentCluster's is origin-keyed to true.

    4. Add the result of creating an agent, given false, to agentCluster.

    5. Set group's agent cluster map[key] to agentCluster.

  7. Return the single similar-origin window agent contained in group's agent cluster map[key].

This means that there is only one similar-origin window agent per browsing context agent cluster. (However, dedicated worker and worklet agents might be in the same cluster.)


The following defines the allocation of the agent clusters of all other types of agents.

To obtain a worker/worklet agent, given an environment settings object or null outside settings, a boolean isTopLevel, and a boolean canBlock, run these steps:

  1. Let agentCluster be null.

  2. If isTopLevel is true, then:

    1. Set agentCluster to a new agent cluster.

    2. Set agentCluster's is origin-keyed to true.

      These workers can be considered to be origin-keyed. However, this is not exposed through any APIs (in the way that originAgentCluster exposes the origin-keyedness for windows).

  3. Otherwise:

    1. Assert: outside settings is not null.

    2. Let ownerAgent be outside settings's realm's agent.

    3. Set agentCluster to the agent cluster which contains ownerAgent.

  4. Let agent be the result of creating an agent given canBlock.

  5. Add agent to agentCluster.

  6. Return agent.

To obtain a dedicated/shared worker agent, given an environment settings object outside settings and a boolean isShared, return the result of obtaining a worker/worklet agent given outside settings, isShared, and true.

To obtain a worklet agent, given an environment settings object outside settings, return the result of obtaining a worker/worklet agent given outside settings, false, and false.

To obtain a service worker agent, return the result of obtaining a worker/worklet agent given null, true, and false.


The following pairs of global objects are each within the same agent cluster, and thus can use SharedArrayBuffer instances to share memory with each other:

The following pairs of global objects are not within the same agent cluster, and thus cannot share memory:

8.1.3 Realms and their counterparts

The JavaScript specification introduces the realm concept, representing a global environment in which script is run. Each realm comes with an implementation-defined global object; much of this specification is devoted to defining that global object and its properties.

For web specifications, it is often useful to associate values or algorithms with a realm/global object pair. When the values are specific to a particular type of realm, they are associated directly with the global object in question, e.g., in the definition of the Window or WorkerGlobalScope interfaces. When the values have utility across multiple realms, we use the environment settings object concept.

Finally, in some cases it is necessary to track associated values before a realm/global object/environment settings object even comes into existence (for example, during navigation). These values are tracked in the environment concept.

8.1.3.1 Environments

An environment is an object that identifies the settings of a current or potential execution environment (i.e., a navigation params's reserved environment or a request's reserved client). An environment has the following fields:

An id

An opaque string that uniquely identifies this environment.

A creation URL

A URL that represents the location of the resource with which this environment is associated.

In the case of a Window environment settings object, this URL might be distinct from its global object's associated Document's URL, due to mechanisms such as history.pushState() which modify the latter.

A top-level creation URL

Null or a URL that represents the creation URL of the "top-level" environment. It is null for workers and worklets.

A top-level origin

A for now implementation-defined value, null, or an origin. For a "top-level" potential execution environment it is null (i.e., when there is no response yet); otherwise it is the "top-level" environment's origin. For a dedicated worker or worklet it is the top-level origin of its creator. For a shared or service worker it is an implementation-defined value.

This is distinct from the top-level creation URL's origin when sandboxing, workers, and worklets are involved.

A target browsing context

Null or a target browsing context for a