The "initialization" steps for Web browsers
allen at wirfs-brock.com
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