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

You might consider that document.write causes a conceptual “in-place” navigation, where the parser is primed with new content from the write() call, and existing elements and their document are disconnected from the window, while a new document and the new elements created from parsing are put in their place. This can happen while script has already taken references to these “old” objects.

Implementations differ on how they handle the scenario. Boris notes that Gecko just creates a new window (with a new document, etc.) just like in navigation. That means that the document (prior) !== document (current). Boris can correct me if I got this wrong.

IE uses an internal mechanism to “re-initialize” the document var, so that document (prior) === document (current), while at the same time swapping out a clean collection of __proto__ hierarchy for the instance. It’s messy code, and we’d like to simplify it a bit, but it is what it is for now.

Chrome, in my testing, does not change anything about the identify of the window or document instances (or the rest of the prototype hierarchy), and just removes the old document.documentElement and starts parsing the new content into the old document (my expandos on the type system and document instance are preserved).

Hopefully this expansion helped :-/

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


Hi Travis, I didn't follow. Could you expand, assuming less background knowledge?  Thanks.
On Jan 14, 2015 2:58 PM, "Travis Leithead" <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
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<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<mailto: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