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

On 1/14/15 3:17 PM, Ian Hickson wrote:
> It's more than that. It's how the HTML spec defines WindowProxy.

The point is, the HTML spec's definition is not expressible in ES terms. 
  So how do go about bridging this gap?

> According to the HTML spec, all operations that would be performed on the
> WindowProxy object must be performed on the Window object of the browsing
> context's active document instead. So the above would set a property on
> the underlying Window object, not the WindowProxy.

It would call the [[DefineOwnProperty]] trap of the WindowProxy.  That 
then forwards to the Window, yes?

> ...but the window proxy's [[GetOwnProperty]] just forwards that straight
> to the Window's [[GetOwnProperty]].

Yes, but since which window it forwards to changes you get an invariant 
violation for the WindowProxy object itself.

> The property is on the Window, not the WindowProxy. It can't disappear
> from the Window. The invariant is thus maintained.

I think you misunderstand what the invariant is.

> There is no way to directly query the WindowProxy.

It doesn't matter.  The user sees the WindowProxy, not the Window. After 
you navigate, you still have the same WindowProxy (e.g. .contentWindow 
returns something that is === to the thing you had before you 
navigated).  But properties it claimed to have that were 
non-configurable are now gone.  That is precisely a violation of the 
invariants.

> To all intents and purposes, it's not a real object.

It looks like an object and quacks like an object.  Sorry, but it's an 
object as far as all consumers are concerned; they have no way to tell 
it apart from an object except _maybe_ via these invariant violations. 
But then you've entered circular argument territory.

> It's a reference to another object

JS doesn't have such a type in the language, sadly, so we can't model it 
that way for consumers.

-Boris

Received on Wednesday, 14 January 2015 22:33:16 UTC