tc39 / proposal-ses

Draft proposal for SES (Secure EcmaScript)
223 stars 20 forks source link

the value of `this` in frozen realms #18

Closed caridy closed 8 years ago

caridy commented 8 years ago

When writing the first draft for the spec, I've encountered the following line in InitializeHostDefinedRealm:

"If the host requires that the this binding in realm's global scope return an object other than the global object, let thisValue be such an object created in an implementation defined manner. Otherwise, let thisValue be undefined, indicating that realm's global this binding should be the global object."

I wonder what's the value of this for spawned realms, and for frozen realms? e.g.:

sharedRoot.spawn().eval('return this')

/cc @erights

erights commented 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.

caridy commented 8 years ago

Ok, we are good. This is what I have so far:

image

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.

allenwb commented 8 years ago

@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.

caridy commented 8 years ago

Perfect.

erights commented 8 years ago

@allenwb By "global problem" did you mean "global object"?

allenwb commented 8 years ago

@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.

allenwb commented 8 years ago

@erights yes, fixed

caridy commented 8 years ago

@allenwb good catch, fixing it!