This is blocked on https://bugs.ecmascript.org/show_bug.cgi?id=3138

This also needs to integrate the event loop as per:
   http://esdiscuss.org/topic/the-initialization-steps-for-web-browsers

https://mail.mozilla.org/pipermail/es-discuss/2014-July/038406.html

  When an event loop is created, invoke the algorithm in 8.5
  Initialization. Step 7 should obtain zero scripts. This results in
  8.4.2 NextTask being invoked. 8.4.2 NextTask is adjusted as follows:

   The "implementation defined unhandled exception processing" in step 1
   must be the "report an error" logic in the HTML spec.

   The "implementation defined manner" for selecting "a non-empty Task
   Queue" in step 4 is to return execution to the calling algorithm;
   subsequent logic in the HTML spec will then resume the NextTask
   algorithm when a new task has been primed.

  When a Window or Worker is created, run 8.5 Initialization steps 1-6,
  except that in 8.5.1 InitializeFirstRealm, "this implementation
  requires use of an exotic object object to serve as realm’s global
  object", namely, the Window or WorkerGlobalScope object. Then, suspend
  the execution context. Stash the realm in the script settings object
  for the Window.

  When you load a <script>, the browser fetches the file, gets the body,
  decodes it to Unicode, and then creates a PendingTask record whose
  [[Task]] is ScriptEvaluationTask, whose [[Arguments]] consists of a
  list with one member, the Unicode characters obtained earlier, and the
  [[Realm]] is the object stashed in the script settings object. That
  record is put in the Task Queue, and then the NextTask algorithm is
  resumed.

Plan:

1. Turn "Creating a browsing context" into a set of steps rather than a paragraph.
2. Factor out the parts in that algorithm and in "Initialising a new Document object" that create new Window objects, creating a new "Create a Window object" algorithm.
3. Make that algorithm call ECMAScript's Initialization() algorithm (from section 8.5 in the ES6 spec), but with:
   - the "implementation dependent manner" in which ECMAScript source texts are to be obtained being to do nothing, finding zero scripts.
   - for the purposes of InitializeHostDefinedRealm, "this implementation requires use of an exotic object", namely, the Window object, and the "implementation defined manner" in which it is created is to run the steps that are currently those for creating Window objects, except that the Realm is also stored in the environment settings object being created with the Window.
   - the Assert in NextJob step 3 being ignored (it can be false e.g. if a page creates an iframe in a script and inserts it into a document then examines its contents, or if showModalDialog is used).
   - the "implementation defined manner" in NextJob step 4, in which a non-empty Job Queue is chosen, being to consider all the Job Queues to be empty.
   - the "implementation defined" "result" in that same step due to all the Job Queues being empty being to abort the NextJob algorithm and return to the "Create a Window object" algorithm.
4. Repeat steps 2 and 3 for worker global objects, changed appropriately.
5. Write a new algorithm for creating an event loop.
6. When an event loop is created, call ECMAScript's Initialization() algorithm (from section 8.5 in the ES6 spec), but with:
   - the "implementation dependent manner" in which ECMAScript source texts are to be obtained being to do nothing, finding zero scripts.
   - the "implementation defined manner" in NextJob step 4, in which a non-empty Job Queue is chosen, being to consider all the Job Queues to be empty.
   - the "implementation defined" "result" in that same step due to all the Job Queues being empty being to suspend the algorithm, save that suspended algorithm as the event loop's "script running algorithm", and return to the caller of the event-loop-creating algorithm.
7. Add an algorithm somewhere that defines that when the event loop needs to run a script, the UA must resume the "script running algorithm", but with:
   - "nextQueue" set to a Job Queue containing one PendingJob record configured appropriately for running this script (see the last paragraph of comment 3).
   - the "implementation defined unhandled exception processing" referenced in NextJob step 1 being to call the "report an error" logic in the HTML spec.
   - the "implementation defined manner" in NextJob step 4, in which a non-empty Job Queue is chosen, being to consider all the Job Queues to be empty.
   - the "implementation defined" "result" in that same step due to all the Job Queues being empty being to suspend the algorithm, save that suspended algorithm as the event loop's "script running algorithm", and return to the caller of the script-running algorithm.
8. Fix step 15 of document.open(); see bug 28563.

Ian, I'm willing to take this on, but I could use some help figuring out a particular detail here.

When doing "implementation defined unhandled exception processing" and calling in to "report an error", we need to get back to the HTML-spec "script" object corresponding to the currently running code in ES's job queue. (This is definitely necessary, because of the muted errors flag if nothing else.) I am not sure how to do this. We could use ES spec meta-variables like "running execution context" or "current realm," but I'm not confident that actually helps.

Do you (or anyone else) have any ideas?

Answering my own question from comment 5: in https://github.com/tc39/ecma262/issues/78 we discovered the right solution. I've copied the basics here for posterity.

In NextJob, we're allowed to "Perform any implementation or host environment defined job initialization using nextPending." We can store details of the HTML script on "the running execution context", and use job.[[HostDefined]] to correlate. When we run scripts from HTML using NextJob(ScriptEvaluationJob, ...), we can store the script in job.[[HostDefined]] to help such correlation. This allows us to go between "running execution context" and HTML "script" with ease.

This work is taking place on https://github.com/whatwg/html/tree/es-init (building on top of https://github.com/whatwg/html/pull/373 and https://github.com/tc39/ecma262/pull/226). I've got most of the initialization stuff done, but not yet the script running stuff. Here are some notes to myself for how this should work, so that I don't forget tomorrow.

"ScriptJobs" queue will always be empty with current setup. (ES only uses it for the initial script discovery, which we always discover zero scripts for.) So we can use it for our own script execution.

How does NextJob transfer PromiseJobs to event loop microtasks? Unclear...

When there are no pending jobs at all, the "result is implementation defined". We suspend the NextJob algorithm at this point and save it as "resume running JavaScript jobs" or something.

When we want to run a script, we EnqueueJob("ScriptJobs", ...) and then "resume running JavaScript jobs" to actually pump the job queue.

What if our JavaScript job enqueues a PromiseJob? We reach NextJob. NextJob sees (or at least has the option to see) a PromiseJob.... what does it do? It grabs it and enqueues a microtask to "resume running JavaScript jobs" perhaps? That doesn't seem airtight, but maybe it is, since we control all ScriptJob enqueuing...

Not too happy with the promise integration, but otherwise this seems straightforward. I guess I'll tackle that last (i.e. will initially commit a solution that ignores PromiseJobs). There's still a decent bit of work to do making sure the realms, scripts, running execution contexts, etc. all line up.

https://github.com/whatwg/html/pull/373 and https://github.com/whatwg/html/pull/401 together complete the work described here. Woohoo!!