Rewrite script execution on top of ES

[domenic]

This is on top of #373; the first three commits are just that PR. However, I am making a separate PR because the changes here depend on tc39/ecma262#242, so this is not mergeable quite yet. It's ready for review though.

---

This brings the script execution parts of the spec up to date with the latest changes in ES. Notable changes include:

• Removed of some generalization to allow non-JavaScript scripting languages (including XML-based ones).
• Let ES track the execution context stack, and the corresponding stack of scripts; see Layering: track execution contexts' script/module tc39/ecma262#242. This allows us to stop tracking the stack of script settings objects, instead defining entry and incumbent settings objects with reference to ES. This is especially important since our current mechanism, of monkey-patching the SourceElement grammatical construction, no longer works since that grammar production has disappeared. Fixes Unclear distinction between "entry" and "incumbent" settings objects #155.
• Established a direct correspondence between HTML's "script" concept and ES's Script Record/Module Record concepts. The former is stored in the [[HostDefined]] slot of the latter.
• The process of parsing and executing scripts, including handling any resulting errors, is now formalized and appropriately calls out to ES's ParseScript and ScriptEvaluation abstract operations.

Note that we do not use the ECMAScript ScriptEvaluationJob or job queue for our script parsing/evaluation. That setup is overengineered and does not serve the needs of HTML; we hope to remove it from ES eventually. (See tc39/ecma262#240 (comment) for details.) Instead we simply use ParseScript and EvaluateScript directly.

This almost completes https://www.w3.org/Bugs/Public/show_bug.cgi?id=25981, with the remaining work item being to integrate promise jobs and ensure they are run as microtasks.

[domenic]

Addressed most review comments, in a separate commit for ease of reviewing. The GitHub UI seems to have lost them so here is the link to the original commit where they were present: da503bf

[annevk]

(I made the comments on the commit directly as the other commits were not applicable to this PR. But I guess that means they do not get tracked as part of the PR review, which seems sad.)

[annevk]

I realize I suggested this, but looking at it "created" probably makes more sense to appear before the term, don't you think?

[domenic]

It's a bit of a weird case; I'm happy to go with whatever. Maybe I should patch ES to return the execution context from InitializeHostDefinedRealm() instead.

[annevk]

Is it fine to not always write realm as Realm? I think other than that this is okay, though having explicit review from the IDL editors would be great. Not sure if @heycam is on vacation too though.

[domenic]

I opened tc39/ecma262#252 about the capitalization of realm. I think it's an editorial issue with ES and they should not capitalize.

[domenic]

I added an additional commit addressing #193, please take a look. Also it looks like tc39/ecma262#242 is about to be merged so I'm looking for final LGTMs.

[domenic]

And I pushed my job queue integration commit into here as well. This finally gives us a normative specification for the fact that promises go on the microtask queue. /cc @bterlson @DigiTec.

[domenic]

OK, I guess ES is using Realm to mean Realm Record, per tc39/ecma262#252. I have capitalized it for the one place it is used in that sense here. The other places are in "realm execution context" where it is an adjective so I left it lowercase.

[domenic]

Newline nit fixed; ready for more review.

[annevk]

What does component-wise mean? Seems like that can be removed without changing the meaning?

[domenic]

The idea was to match the previous text (in "support the scripting language"):

if each component of the script block's type is an ASCII case-insensitive match for the corresponding component in the MIME type string of a scripting language that the user agent implements.

I considered other phrasing, like

For each JavaScript MIME type, check whether the script block's type is an ASCII case-insensitive match for the corresponding component in the JavaScript MIME type string. If all such checks fail, then the user agent must abort these steps at this point.

But that seemed verbose and a bit confusing.

Upon reflection I think I agree you can just do a string comparison, so I will amend it as you suggest.

[domenic]

I guess I should add back "do not merge yet" until @bterlson pushes another snapshot for the JS spec. Bah, continuous deployment is so much nicer :).

[annevk]

I'll just note that what I reviewed looks good. I would be more comfortable with review from the IDL folks, but since @domenic is committed to maintaining this I'm fine with merging this once ECMAScript is ready and then seeking review from IDL folks on the merged text.

[bzbarsky]

@domenic The new definition of incumbent settings object seems broken to me.

In particular, I don't see how propagating it across Web IDL callbacks works. Think things like:

setTimeout(someWindow.postMessage.bind(someWindow, stuff), 0);

and what the incumbent settings object will be when postMessage is invoked. What will it be with the spec as it's written right now.

I assume the entry settings object in this case will be something sane-ish, in that it will be associated with the Function that is the return value of bind in this case, right?

[bzbarsky]

Oh, and importantly are there ever JavaScript execution contexts that do not have a script or a module associated with them? If not, why not? What is the ScriptOrModule when the callback function is called in the case above?

[bzbarsky]

Digging into the ES end of this a bit more, builtin functions have [[ScriptOrModule]] set to null, afaict. See https://tc39.github.io/ecma262/#sec-createbuiltinfunction

A bound function isn't even a Function object in terms of the ES spec, afaict. It's created in https://tc39.github.io/ecma262/#sec-boundfunctioncreate and just has a special [[Call]]. So it would not have a [[ScriptOrModule]] of its own. Given that, calling GetActiveScriptOrModule inside that postMessage invocation seems like it would fail the assert in step 5. This happens because https://tc39.github.io/ecma262/#sec-built-in-function-objects-call-thisargument-argumentslist will set the running execution context to the calleeContext, which gets F's [[ScriptOrModule]], which as noted above is null.

[bzbarsky]

@domenic As far as entry settings objects... I'm not sure what "the script corresponding to the running execution context" is in the EnqueueJob section in the HTML spec. Why would there be such a script at all? See builtin functions above.

I'm not quite sure what used to set up entry settings objects for the case of callbacks backed by either builtin functions or worse yet bound builtin functions. And worse yet bound builtin where the bind comes from a different Realm than the builtin. A testcase:

<script>
  onerror = function() { console.log("Parent error"); }
  onload = function() {
    frames[0].onerror = function() { console.log("Child error"); };
    frames[0].setTimeout(document.querySelector.bind(document), 0);
    frames[0].setTimeout(frames[0].Function.prototype.bind.call(document.querySelector, document), 0);
  }
</script>
<iframe></iframe>

I believe the real intent of the spec as it stood before these changes is that this should log "Parent error" followed by "Child error", though it's worth testing what UAs actually do here. At least IE and Firefox and the spec used to agree on the first thing being logged being "Parent error" in this case, last I checked.