相关文章推荐
  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 )
        3. 8.1.6.3 HostPromiseRejectionTracker( promise , operation )
        4. 8.1.6.4 Job-related host hooks
          1. 8.1.6.4.1 HostCallJobCallback( callback , V , argumentsList )
          2. 8.1.6.4.2 HostEnqueueFinalizationRegistryCleanupJob( finalizationRegistry )
          3. 8.1.6.4.3 HostEnqueueGenericJob( job , realm )
          4. 8.1.6.4.4 HostEnqueuePromiseJob( job , realm )
          5. 8.1.6.4.5 HostEnqueueTimeoutJob( job , realm , milliseconds )
          6. 8.1.6.4.6 HostMakeJobCallback( callable )
        5. 8.1.6.5 Module-related host hooks
          1. 8.1.6.5.1 HostGetImportMetaProperties( moduleRecord )
          2. 8.1.6.5.2 HostGetSupportedImportAttributes()
          3. 8.1.6.5.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 .

    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. Set agentCluster 's is origin-keyed to true if key equals origin ; otherwise false.

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

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

  6. 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.

    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).

      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 .

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

    4. Add agent to agentCluster .

    5. 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 navigation request .

    An active service worker

    Null or a service worker that controls the environment .

    An execution ready flag

    A flag that indicates whether the environment setup is done. It is initially unset.

    Specifications may define environment discarding steps for environments. The steps take an environment as input.

    The environment discarding steps are run for only a select few environments: the ones that will never become execution ready because, for example, they failed to load.

    8.1.3.2 Environment settings objects

    An environment settings object is an environment that additionally specifies algorithms for:

    A realm execution context

    A JavaScript execution context shared by all scripts that use this settings object, i.e., all scripts in a given realm . When we run a classic script or run a module script , this execution context becomes the top of the JavaScript execution context stack , on top of which another execution context specific to the script in question is pushed. (This setup ensures ParseScript and Source Text Module Record 's Evaluate know which realm to use.)

    A module map

    A module map that is used when importing JavaScript modules.

    An API URL character encoding

    A character encoding used to encode URLs by APIs called by scripts that use this environment settings object .

    An API base URL

    A URL used by APIs called by scripts that use this environment settings object to parse URLs .

    An origin

    An origin used in security checks.

    A policy container

    A policy container containing policies used for security checks.

    A cross-origin isolated capability

    A boolean representing whether scripts that use this environment settings object are allowed to use APIs that require cross-origin isolation.

    A time origin
    A number used as the baseline for performance-related timestamps. [HRT]

    An environment settings object also has an outstanding rejected promises weak set and an about-to-be-notified rejected promises list , used to track unhandled promise rejections . The outstanding rejected promises weak set must not create strong references to any of its members, and implementations are free to limit its size, e.g. by removing old entries from it when new ones are added.

    An environment settings object 's responsible event loop is its global object 's relevant agent 's event loop .

    8.1.3.3 Realms, settings objects, and global objects

    A global object is a JavaScript object that is the [[GlobalObject]] field of a realm .

    In this specification, all realms are created with global objects that are either Window , WorkerGlobalScope , or WorkletGlobalScope objects.

    There is always a 1-to-1-to-1 mapping between realms , global objects , and environment settings objects :

    To create a new realm in an agent agent , optionally with instructions to create a global object or a global this binding (or both), the following steps are taken:

    1. Perform InitializeHostDefinedRealm () with the provided customizations for creating the global object and the global this binding.

    2. Let realm execution context be the running JavaScript execution context .

      This is the JavaScript execution context created in the previous step.

    3. Remove realm execution context from the JavaScript execution context stack .

    4. Let realm be realm execution context 's Realm component.

    5. If agent 's agent cluster 's cross-origin isolation mode is " none ", then:

      1. Let global be realm 's global object .

      2. Let status be ! global .[[Delete]](" SharedArrayBuffer ").

      3. Assert : status is true.

      This is done for compatibility with web content and there is some hope that this can be removed in the future. Web developers can still get at the constructor through new WebAssembly.Memory({ shared:true, initial:0, maximum:0 }).buffer.constructor .

    6. Return realm execution context .

    When defining algorithm steps throughout this specification, it is often important to indicate what realm is to be used—or, equivalently, what global object or environment settings object is to be used. In general, there are at least four possibilities:

    Entry
    This corresponds to the script that initiated the currently running script action: i.e., the function or script that the user agent called into when it called into author code.
    Incumbent
    This corresponds to the most-recently-entered author function or script on the stack, or the author function or script that originally scheduled the currently-running callback.
    Current
    This corresponds to the currently-running function object, including built-in user-agent functions which might not be implemented as JavaScript. (It is derived from the current realm .)
    Relevant
    Every platform object has a relevant realm , which is roughly the realm in which it was created. When writing algorithms, the most prominent platform object whose relevant realm might be important is the this value of the currently-running function object. In some cases, there can be other important relevant realms , such as those of any arguments.

    Note how the entry , incumbent , and current concepts are usable without qualification, whereas the relevant concept must be applied to a particular platform object .

    The incumbent and entry concepts should not be used by new specifications, as they are excessively complicated and unintuitive to work with. We are working to remove almost all existing uses from the platform: see issue #1430 for incumbent , and issue #1431 for entry .

    In general, web platform specifications should use the relevant concept, applied to the object being operated on (usually the this value of the current method). This mismatches the JavaScript specification, where current is generally used as the default (e.g., in determining the realm whose Array constructor should be used to construct the result in Array.prototype.map ). But this inconsistency is so embedded in the platform that we have to accept it going forward.

    Consider the following pages, with a.html being loaded in a browser window, b.html being loaded in an iframe as shown, and c.html and d.html omitted (they can simply be empty documents):

    <!-- a.html -->
    <!DOCTYPE html>
    <html lang="en">
    <title>Entry page</title>
    <iframe src="b.html"></iframe>
    <button onclick="frames[0].hello()">Hello</button>
    <!--b.html -->
    <!DOCTYPE html>
    <html lang="en">
    <title>Incumbent page</title>
    <iframe src="c.html" id="c"></iframe>
    <iframe src="d.html" id="d"></iframe>
    <script>
      const c = document.querySelector("#c").contentWindow;
      const d = document.querySelector("#d").contentWindow;
      window.hello = () => {
        c.print.call(d);
    </script>

    Each page has its own browsing context , and thus its own realm , global object , and environment settings object .

    When the print() method is called in response to pressing the button in a.html , then:

    One reason why the relevant concept is generally a better default choice than the current concept is that it is more suitable for creating an object that is to be persisted and returned multiple times. For example, the navigator.getBattery() method creates promises in the relevant realm for the Navigator object on which it is invoked. This has the following impact: [BATTERY]

    <!-- outer.html -->
    <!DOCTYPE html>
    <html lang="en">
    <title>Relevant realm demo: outer page</title>
    <script>
      function doTest() {
        const promise = navigator.getBattery.call(frames[0].navigator);
        console.log(promise instanceof Promise);           // logs false
        console.log(promise instanceof frames[0].Promise); // logs true
        frames[0].hello();
    </script>
    <iframe src="inner.html" onload="doTest()"></iframe>
    <!-- inner.html -->
    <!DOCTYPE html>
    <html lang="en">
    <title>Relevant realm demo: inner page</title>
    <script>
      function hello() {
        const promise = navigator.getBattery();
        console.log(promise instanceof Promise);        // logs true
        console.log(promise instanceof parent.Promise); // logs false
    </script>

    If the algorithm for the getBattery() method had instead used the current realm , all the results would be reversed. That is, after the first call to getBattery() in outer.html , the Navigator object in inner.html would be permanently storing a Promise object created in outer.html 's realm , and calls like that inside the hello() function would thus return a promise from the "wrong" realm. Since this is undesirable, the algorithm instead uses the relevant realm , giving the sensible results indicated in the comments above.

    The rest of this section deals with formally defining the entry , incumbent , current , and relevant concepts.

    8.1.3.3.1 Entry

    The process of calling scripts will push or pop realm execution contexts onto the JavaScript execution context stack , interspersed with other execution contexts .

    With this in hand, we define the entry execution context to be the most recently pushed item in the JavaScript execution context stack that is a realm execution context . The entry realm is the entry execution context 's Realm component.

    Then, the entry settings object is the environment settings object of the entry realm .

    Similarly, the entry global object is the global object of the entry realm .

    8.1.3.3.2 Incumbent

    All JavaScript execution contexts must contain, as part of their code evaluation state, a skip-when-determining-incumbent counter value, which is initially zero. In the process of preparing to run a callback and cleaning up after running a callback , this value will be incremented and decremented.

    Every event loop has an associated backup incumbent settings object stack , initially empty. Roughly speaking, it is used to determine the incumbent settings object when no author code is on the stack, but author code is responsible for the current algorithm having been run in some way. The process of preparing to run a callback and cleaning up after running a callback manipulate this stack. [WEBIDL]

    When Web IDL is used to invoke author code, or when HostEnqueuePromiseJob invokes a promise job, they use the following algorithms to track relevant data for determining the incumbent settings object :

    To prepare to run a callback with an environment settings object settings :

    1. Push settings onto the backup incumbent settings object stack .

    2. Let context be the topmost script-having execution context .

    3. If context is not null, increment context 's skip-when-determining-incumbent counter .

    To clean up after running a callback with an environment settings object settings :

    Let context be the topmost script-having execution context .

    This will be the same as the topmost script-having execution context inside the corresponding invocation of prepare to run a callback .

  2. If context is not null, decrement context 's skip-when-determining-incumbent counter .

  3. Assert : the topmost entry of the backup incumbent settings object stack is settings .

  4. Remove settings from the backup incumbent settings object stack .

Here, the topmost script-having execution context is the topmost entry of the JavaScript execution context stack that has a non-null ScriptOrModule component, or null if there is no such entry in the JavaScript execution context stack .

With all this in place, the incumbent settings object is determined as follows:

  1. Let context be the topmost script-having execution context .

  2. If context is null, or if context 's skip-when-determining-incumbent counter is greater than zero, then:

    Assert : the backup incumbent settings object stack is not empty.

    This assert would fail if you try to obtain the incumbent settings object from inside an algorithm that was triggered neither by calling scripts nor by Web IDL invoking a callback. For example, it would trigger if you tried to obtain the incumbent settings object inside an algorithm that ran periodically as part of the event loop , with no involvement of author code. In such cases the incumbent concept cannot be used.

  3. Return the topmost entry of the backup incumbent settings object stack .

  • Return context 's Realm component's settings object .

  • Then, the incumbent realm is the realm of the incumbent settings object .

    Similarly, the incumbent global object is the global object of the incumbent settings object .

    The following series of examples is intended to make it clear how all of the different mechanisms contribute to the definition of the incumbent concept:

    Consider the following starter example:

    <!DOCTYPE html>
    <iframe></iframe>
    <script>
      frames[0].postMessage("some data", "*");
    </script>

    There are two interesting environment settings objects here: that of window , and that of frames[0] . Our concern is: what is the incumbent settings object at the time that the algorithm for postMessage() executes?

    It should be that of window , to capture the intuitive notion that the author script responsible for causing the algorithm to happen is executing in window , not frames[0] . This makes sense: the window post message steps use the incumbent settings object to determine the source property of the resulting MessageEvent , and in this case window is definitely the source of the message.

    Let us now explain how the steps given above give us our intuitively-desired result of window 's relevant settings object .

    When the window post message steps look up the incumbent settings object , the topmost script-having execution context will be that corresponding to the script element: it was pushed onto the JavaScript execution context stack as part of ScriptEvaluation during the run a classic script algorithm. Since there are no Web IDL callback invocations involved, the context's skip-when-determining-incumbent counter is zero, so it is used to determine the incumbent settings object ; the result is the environment settings object of window .

    (Note how the environment settings object of frames[0] is the relevant settings object of this at the time the postMessage() method is called, and thus is involved in determining the target of the message. Whereas the incumbent is used to determine the source .)

    Consider the following more complicated example:

    <!DOCTYPE html>
    <iframe></iframe>
    <script>
      const bound = frames[0].postMessage.bind(frames[0], "some data", "*");
      window.setTimeout(bound);
    </script>

    This example is very similar to the previous one, but with an extra indirection through Function.prototype.bind as well as setTimeout() . But, the answer should be the same: invoking algorithms asynchronously should not change the incumbent concept.

    This time, the result involves more complicated mechanisms:

    When bound is converted to a Web IDL callback type, the incumbent settings object is that corresponding to window (in the same manner as in our starter example above). Web IDL stores this as the resulting callback value's callback context .

    When the task posted by setTimeout() executes, the algorithm for that task uses Web IDL to invoke the stored callback value. Web IDL in turn calls the above prepare to run a callback algorithm. This pushes the stored callback context onto the backup incumbent settings object stack . At this time (inside the timer task) there is no author code on the stack, so the topmost script-having execution context is null, and nothing gets its skip-when-determining-incumbent counter incremented.

    Invoking the callback then calls bound , which in turn calls the postMessage() method of frames[0] . When the postMessage() algorithm looks up the incumbent settings object , there is still no author code on the stack, since the bound function just directly calls the built-in method. So the topmost script-having execution context will be null: the JavaScript execution context stack only contains an execution context corresponding to postMessage() , with no ScriptEvaluation context or similar below it.

    This is where we fall back to the backup incumbent settings object stack . As noted above, it will contain as its topmost entry the relevant settings object of window . So that is what is used as the incumbent settings object while executing the postMessage() algorithm.

    Consider this final, even more convoluted example:

    <!-- a.html -->
    <!DOCTYPE html>
    <button>click me</button>
    <iframe></iframe>
    <script>
    const bound = frames[0].location.assign.bind(frames[0].location, "https://example.com/");
    document.querySelector("button").addEventListener("click", bound);
    </script>
    <!-- b.html -->
    <!DOCTYPE html>
    <iframe src="a.html"></iframe>
    <script>
      const iframe = document.querySelector("iframe");
      iframe.onload = function onLoad() {
        iframe.contentWindow.document.querySelector("button").click();
    </script>

    Again there are two interesting environment settings objects in play: that of a.html , and that of b.html . When the location.assign() method triggers the Location -object navigate algorithm, what will be the incumbent settings object ? As before, it should intuitively be that of a.html : the click listener was originally scheduled by a.html , so even if something involving b.html causes the listener to fire, the incumbent responsible is that of a.html .

    The callback setup is similar to the previous example: when bound is converted to a Web IDL callback type, the incumbent settings object is that corresponding to a.html , which is stored as the callback's callback context .

    When the click() method is called inside b.html , it dispatches a click event on the button that is inside a.html . This time, when the prepare to run a callback algorithm executes as part of event dispatch, there is author code on the stack; the topmost script-having execution context is that of the onLoad function, whose skip-when-determining-incumbent counter gets incremented. Additionally, a.html 's environment settings object (stored as the EventHandler 's callback context ) is pushed onto the backup incumbent settings object stack .

    Now, when the Location -object navigate algorithm looks up the incumbent settings object , the topmost script-having execution context is still that of the onLoad function (due to the fact we are using a bound function as the callback). Its skip-when-determining-incumbent counter value is one, however, so we fall back to the backup incumbent settings object stack . This gives us the environment settings object of a.html , as expected.

    Note that this means that even though it is the iframe inside a.html that navigates, it is a.html itself that is used as the source Document , which determines among other things the request client . This is perhaps the only justifiable use of the incumbent concept on the web platform ; in all other cases the consequences of using it are simply confusing and we hope to one day switch them to use current or relevant as appropriate.

    8.1.3.3.3 Current

    The JavaScript specification defines the current realm , also known as the "current Realm Record". [JAVASCRIPT]

    Then, the current settings object is the environment settings object of the current realm .

    Similarly, the current global object is the global object of the current realm .

    8.1.3.3.4 Relevant

    The relevant realm for a platform object is the value of its [[Realm]] field .

    Then, the relevant settings object for a platform object o is the environment settings object of the relevant realm for

    Similarly, the relevant global object for a platform object o is the global object of the relevant realm for

    8.1.3.4 Enabling and disabling scripting

    Scripting is enabled for an environment settings object settings when all of the following conditions are true:

     
    推荐文章