The "initialization" steps for Web browsers

Allen Wirfs-Brock allen at
Wed Jul 23 09:45:10 PDT 2014

On Jul 23, 2014, at 9:31 AM, Boris Zbarsky wrote:

> On 7/23/14, 12:02 PM, Allen Wirfs-Brock wrote:
>> No, synchronous dispatchEvent looks like it could just work depending
>> upon  how the browser specific contextual state (origin, etc. scripting
>> settings, etc. in the HTML spec.) is modeled.
> It's modeled as "settings objects" (settings records, if you prefer). Mostly.  "origin" and "effective script origin" are computed from stuff in the settings record.
>> If dispatchEvent is going to synchronously dispatch event handlers it may
>> have to do browser context switch for each handler.  How does it know to
>> do this?
> Web IDL callbacks store the info they need to set up the call.
>> Perhaps we also need a [[HostDefined]] field in Realm records?
>> (Each function is associated with a realm, so it is a good place to put
>> context that is shared by all functions for a specific realm).

Yes, but how does that then map into the ES invocation model.  If even handlers are just ordinary ES functions with an ordinary [[Call]] how do you ensure that the  necessary browser context is established when they are invoked from an arbitrary place?

> In practice, each Realm has a unique global and the HTML spec ends up hanging its stuff off there as far as I can tell.

I added [[HostDefined]] to jobs after we had a conversation that I believe was about maintaining a dynamic stack of script origins as code executes. At the time, you indicated tht you thought it was a sufficient hook. Do you still think that?  It's not clear to me how what we are discussing now relates to that.


More information about the es-discuss mailing list