On Thu, 4 Dec 2014, Boris Zbarsky wrote:
> On 12/4/14, 1:36 PM, Travis Leithead wrote:
> >
> > 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.
>
> That's an IE implementation detail.
It's more than that. It's how the HTML spec defines WindowProxy.
> So when a script does:
>
> Object.defineProperty(frames[0], "foo", { value: true; });
>
> It is defining a property on frames[0]. The fact that this is actually
> a proxy for some other object (the global inside that iframe) is
> somewhat of an implementation detail, again.
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.
> This isn't about "appearance". The relevant spec invariant for
> [[GetOwnProperty]], for example, is:
>
> If P’s attributes other than [[Writable]] may change over time or
> if the property might disappear, then P’s [[Configurable]] attribute
> must be true.
>
> And Object.getOwnPropertyDescriptor is clearly defined to invoke
> [[GetOwnProperty]].
>
> So when a page does Object.getOwnPropertyDescriptor(window, "foo") this
> is invoking the window proxy's [[GetOwnProperty]].
...but the window proxy's [[GetOwnProperty]] just forwards that straight
to the Window's [[GetOwnProperty]].
The property is on the Window, not the WindowProxy. It can't disappear
from the Window. The invariant is thus maintained.
There is no way to directly query the WindowProxy. To all intents and
purposes, it's not a real object. It's a reference to another object,
which happens to change during navigation.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 14 January 2015 20:18:22 UTC