RE: Figuring out the behavior of WindowProxy in the face of non-configurable properties



> -----Original Message-----
> From: Boris Zbarsky [mailto:bzbarsky@mit.edu]
> Sent: Thursday, December 4, 2014 11:11 AM
> To: Travis Leithead; Mark S. Miller
> Cc: es-discuss; public-script-coord@w3.org; Domenic Denicola
> Subject: Re: Figuring out the behavior of WindowProxy in the face of non-
> configurable properties
> 
> On 12/4/14, 10:44 AM, Travis Leithead wrote:
> > So... this will prevent defining non-configurable properties on the global?
> 
> It will prevent using
> 
>    Object.defineProperty(window, "name",  non-configurable-descriptor);
> 
> to define a property.
> 
> Note that "window" is not the global.  It's a proxy whose target is the global.

Yes, but within a browser UA, there is no way to get a reference to the naked global because all entry-points return window proxies ;-)

> > Combined with [PrimaryGlobal], this seems at odds with what browsers do
> internally to prevent re-definition of some properties like "document"?
> 
> Browsers can define properties on the actual global, so there is no problem
> here.
> 
> > Are we sure we want this restriction?
> 
> Well, good question.  If we don't do this restriction (by which I assume
> defineProperty throwing; I assume getOwnPropertyDescriptor claiming
> configurable always is less controversial), what do we want to do?

As I look back on your original message, I fail to see what the problem is. You seem to think that the window proxy is referring to the same window object before and after the navigation. In fact, in most implementations that I'm aware of, there is the concept of the "inner" and "outer" window. The "outer" window is the window proxy, which is the object that implements the cross-origin access control. The "inner" window is the JS global that actually stores stuff. In IE's implementation, the window proxy has no storage as a typical JS var--it's only a semi-intelligent forwarder to its companion "inner" window. So, in your code sample, your "defineProperty" call forwarded to the "inner" window where the property was defined. After the navigation, the "inner" window was swapped out for a new one (and whole new type system at that) which the existing window proxy ("outer" window) now refers. This gave the appearance of the non-configurable property disappearing, but in reality it would still be there if you could get a reference to the "inner" window--which you can't* because all places that return a window return only the window proxy :)

*I wonder if you can capture the inner window in a scope chain or closure somehow, so that you could observe that "foo" is still there even though you can't directly see it anymore? I think that might work if the executing code was defined in the old iframe's environment and executed after navigation...

> 
> Note that I did a bit of digging into the history here and as far as I can tell
> every single UA screwed up when implementing
> Object.getOwnPropertyDescriptor and company in ES5.  ES5 clearly spells out
> the rules for these methods, and browsers just didn't follow those rules.
> Plus lack of testing and here we are.
> 
> -Boris

Received on Thursday, 4 December 2014 21:36:55 UTC