Figuring out the behavior of WindowProxy in the face of non-configurable properties
bzbarsky at mit.edu
Wed Jan 14 14:32:45 PST 2015
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
> 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.
More information about the es-discuss