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

WindowProxies are going to be a challenge when it comes to a pure ES implementation. The other challenge that just came to mind, is the document object—at least in Gecko and IE: a document.write call will “re-init” the object (subbing out the old var for a new one) while maintaining the === invariant. Chrome appears to have a simpler model for dealing with this. I’m not sure what HTML has to say about this currently…

From: Mark S. Miller [mailto:erights@google.com]
Sent: Wednesday, January 14, 2015 2:44 PM
To: Boris Zbarsky
Cc: Ian Hickson; Travis Leithead; Domenic Denicola; public-script-coord@w3.org; es-discuss
Subject: Re: Figuring out the behavior of WindowProxy in the face of non-configurable properties

Boris has this exactly right. Further, a malicious proxy handler can leverage the presence of a single object that violates these invariants into the creation of arbitrary other proxies objects that also violate these invariants. The key is that the enforcement of the invariants relies on the proxy's target being constrained by these invariants.

See http://research.google.com/pubs/pub40736.html




On Wed, Jan 14, 2015 at 2:32 PM, Boris Zbarsky <bzbarsky@mit.edu<mailto:bzbarsky@mit.edu>> wrote:
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



--
    Cheers,
    --MarkM