diff --git a/source b/source index 4f540040816..957b0a191aa 100644 --- a/source +++ b/source @@ -2915,6 +2915,7 @@ a.setAttribute('href', 'http://example.com/'); // change the content attribute d
  • Callback this value
  • Converting between WebIDL types and JS types
  • invoke the Web IDL callback function +
  • callback context

    The Web IDL specification also defines the following types that are used in Web IDL fragments @@ -86418,12 +86419,12 @@ interface NavigatorOnLine {

  • Assert: settings's realm execution context is the running JavaScript execution context.

    • -

  • Decrement settings's realm execution context's entrance - counter by one.

    • -

  • Remove settings's realm execution context from the JavaScript execution context stack.

    • +

  • Decrement settings's realm execution context's entrance + counter by one.

    • +

  • If the JavaScript execution context stack is now empty, run the global script clean-up jobs. (These cannot run scripts.)

    • @@ -86677,16 +86678,39 @@ interface NavigatorOnLine {
    Incumbent
    +

    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. When Web IDL is used to invoke author code, it manipulates this stack.

    +

    The incumbent settings object is determined as follows:

    1. Let scriptOrModule be the result of JavaScript's GetActiveScriptOrModule() abstract operation.

      2. -

    2. If scriptOrModule is null, abort these steps; there is no - incumbent settings object.

      3. -

    3. Return the settings object of the script in - scriptOrModule's [[HostDefined]] field.

      4. + +

    4. If scriptOrModule is not null, return the settings object of the + script in scriptOrModule's [[HostDefined]] + field.

      5. + +
    5. +

      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.

      +
      6. + +

    6. Return the topmost entry of the backup incumbent settings object + stack.

    Then, the incumbent Realm is the NavigatorOnLine { global object of the incumbent settings object.

    +
    +

    Consider the following very simple example:

    + + 
    <!DOCTYPE html>
+<script>
+  new Worker('worker.js');
+</script>
    + +

    When the Worker() constructor looks at the incumbent + settings object to use for various parts of its algorithm, GetActiveScriptOrModule() will return the JavaScript + Script Record corresponding to the script element. The corresponding + JavaScript execution context was pushed as part of ScriptEvaluation during the run a classic script + algorithm.

    +
    + +
    +

    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>
    + +

    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]. Another way of capturing the + intuition here is that invoking algorithms asynchronously (in this case via setTimeout()) should not change the incumbent concept.

    + +

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

    + +

    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 simple 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. This + pushes the stored callback context onto the backup incumbent settings object + stack. Invoking the callback then calls bound, which in turn calls + the postMessage() method of frames[0].

    + +

    Note that since postMessage() is a built-in + method, the act of calling it does not add any execution contexts to the JavaScript + execution context stack that have a ScriptOrModule component. Thus, when the postMessage() algorithm looks up the incumbent + settings object, GetActiveScriptOrModule() will return 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. Web IDL + set us up so that the stack contains the relevant settings object of window, so that is what is used as the incumbent settings object + while executing the postMessage() algorithm.

    +
    +
    Current

    The JavaScript specification defines the current Realm Record, sometimes