The "initialization" steps for Web browsers

Allen Wirfs-Brock allen at
Mon Jul 21 13:32:43 PDT 2014

On Jul 21, 2014, at 10:49 AM, Ian Hickson wrote:

> On Tue, 10 Jun 2014, Ian Hickson wrote:
>> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
>>> By an ECMAScript Environment (and this is what Ecma-262 defines, 
>>> although it doesn't actually use that name) I mean a heap of 
>>> ECMAScript objects (and related values) that may directly reference 
>>> (point to) each other and a single thread of execution of ECMAScript 
>>> code.  The environment may include multiple "global objects".
>> Ok. Sounds like that mays to an event loop, on the HTML side.
>> That should be quite workable. I'll invoke 8.5 when I create an event 
>> loop (with zero scripts), and I'll invoke CreateRealm() and then 8.5.1 
>> when I create a Window.
> So I started trying to figure out how this would work, but I'm still 
> having trouble (sorry).
> When an event loop is created, we invoke the algorithm in 8.5 
> Initialization, with step 7 set to obtain zero scripts, right?. Now, the 
> user opens a tab or something, and so a Window object needs to be created. 
> What do I do, exactly? Do I need to create a new realm? New execution 
> context? Both? Do I basically do steps 1-5 of the Initialization steps 
> again? I guess I do nothing else until I see a <script>; then what do I 
> do? do I create a PendingTask record for the execution of the script, push 
> it to the front of the Task Queue, and let 9.5's NextTask call procede 
> with this new task?

The abstract operation InitializeFirstRealm is really about setting up the initial environment that will run for actual"user" script code. In other words it is what you would want to set up when the first tab or whatever is opened.  So if there is no ES code to execution prior to that first user action then you might defer the whole 8.5 initialization process until then.  However, if there is some other way to acquire and execute ES code prior to such a user action (for example, FF chrome code, a startup script, etc.) when you would have to do 8.5 initialization earlier.  You might use the "first Realm" for that code or you might use the "first Realm" as sort of system utility realm, if you have a use for such a thing.

The ES spec. currently only has two places a a complete new Realm is created and initialized with a new global object, etc.  The places are 8.5.1 InitializeFirstRealm and the Reflect.Realm constructor. However, would normally be invoked from ES code.  8.5.1 is perhaps misnamed as it provides the default steps that a host would use to initialize any host created realm. In other words, for each window/tab you probably want to follow the steps of 8.5.1 to initialize the associated realm.  It sounds like I need to give InitializeFirstRealm a better name, such as InitializeHostDefinedRealm.

You're right that for each new host created realm you want to repeat steps 1-5 of 8.5.  You don't need to have an empty execution context stack to do that initialization although that might actually be the case if the engine is idling waiting for some user initialized action.  You're also correct about handling scripts. For each <script> that is ready to be processed (the source code has been retrieved) you just enqueue a PendingJob record for a ScriptEvaluationJob (15.1.9) with the realm for the job set to the realm that the <script> runs within.  Again, walking through this I can see that I should probably do a little refactoring to make these steps clearer.


More information about the es-discuss mailing list