Closed caridy closed 8 years ago
I strongly suspect that the strange spec language here is in order to allow the browser's bizarre behavior regarding Window vs WindowProxy. Since this is not an issue for frozen realms or realms spawned from them, a realm's this
should always be that realm's global object.
@allenwb Do I correctly understand the purpose of this strange spec language?
sharedRoot.spawn().eval('return this')
should be that new spawned realm's global object.
Ok, we are good. This is what I have so far:
When spawning, code path described by 4.a will be used, while the step 10 will guarantee that the new object is used as global and as this
in the new realm (that's what undefined those there).
If that looks good, and @allenwb doesn't see any problem, I can close this one.
@erights yup, it allows the creator of a realm to provide in the object to use as the global object. Note that the following line is a call to SetRealmGlobalObject which will allocate an Ordinary Object to serve as the Realm global object if its caller did not provide one.
Perfect.
@allenwb By "global problem" did you mean "global object"?
@caridy Note that SetRealmGlobalObject will allocate a global object if undefined is passed in as its second argument. That means you really don't need to do the ObjectCreate in step 4.a.
One difference between letting SetRealmGlobalObject do the allocation and what you are doing is that your code sets the [[Prototype]] of the new realm's global object to %ObjectPrototype% of the Realm of the Realm constructor that is being evaluated while SetRealmGlobalObject sets the [[Prototype]] to the %ObjectPrototype% of the new realm.
@erights yes, fixed
@allenwb good catch, fixing it!
When writing the first draft for the spec, I've encountered the following line in InitializeHostDefinedRealm:
I wonder what's the value of
this
for spawned realms, and for frozen realms? e.g.:/cc @erights