A DOM use case that can't be emulated with direct proxies

Brendan Eich brendan at mozilla.com
Thu Dec 13 22:12:56 PST 2012

David Bruant wrote:
> Le 12/12/2012 21:42, Kevin Reid a écrit :
>> On Wed, Dec 12, 2012 at 12:35 PM, David Bruant <bruant.d at gmail.com 
>> <mailto:bruant.d at gmail.com>> wrote:
>>     I was a bit too strong in my statement, sorry. Let me rephrase:
>>     the internal [[Target]] can't be changed, but a proxy can emulate
>>     changing of "fake" target as long as what happens with this
>>     "fake" target doesn't involve invariant checking.
>>     That's the reason I was suggesting that WindowProxies could
>>     (maybe depending on how the object reference was obtained) throw
>>     whenever invariant checks are involved.
>> Exactly. So a user-defined switching proxy needs only to:
>> 1. refuse to commit to any invariant (non-configurable property or 
>> preventExtensions)
>> 2. even if its switchable-target has an invariant, do not expose that 
>> invariant (i.e. pretend each property is configurable)
> Pretend that something non-configurable actually is configurable is an 
> invariant violation. To be more concrete:
> * There is an webpage with an iframe
> * The same window object is proxied by 2 WindowProxy instances. One 
> outside the iframe, one inside.

Just as a point of fact regarding the web-as-it-is, this can't happen, 
right? There's only one WindowProxy per Window and it is the only object 
referenced by any JS variable. JS code cannot construct another aliasing 

> * Inside of the iframe, scripts can add a non-configurable property 
> "azerty" to their global.

Boris Zbarsky pointed out on public-script-coord that window.location 
and window.document must be non-configurable _ab initio_, but perhaps 
this is achievable with direct proxies?


> * Outside the iframe, what happens when 
> Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
> You're suggesting that {configurable: true} is returned. The problem 
> is that on the actual Window instance, there is a non-configurable 
> property, so if the WindowProxy handler tries to do that, an error 
> will be thrown because of invariant checks.
> I think throwing is the correct behavior here. The handler can't tell 
> the truth about non-configurable properties (because a later different 
> target may not have the same non-configurable properties), but also 
> can't lie, because lies involves throwing... well, since I say that 
> throwing is the correct behavior, I guess lying is too in a way.
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list