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. Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
