A DOM use case that can't be emulated with direct proxies

[David Bruant]

Hi,

A good question by Anne van Kesteren [1] followed by good remarks by 
Boris Zbarsky [2][3] made me try a little something [4][5].
The WindowProxy object returned as the 'contentWindow' property of 
iframes never changes; whatever you do when changing the @src, always 
the same object is returned. However, based on whether the @src is 
changed, the WindowProxy proxies to a different Window instance.
I thing this is something that can't be implemented with direct proxies. 
Is this conclusion shared?

Assuming I'm not wrong in my analysis, now is time to wonder if the 
direct proxy design should be change to make this part writable in 
JavaScript. If self-hosting the browser APIs as pure ECMAScript 6 is a 
goal, something needs to be changed indeed.
If it's possible to relax this use case a little bit, following the 
direct proxies model described some time ago [6], it would be possible 
to do the following:
* Model WindowProxy objects as ES proxies
* Allow the UA to change the target of this proxy at will (which is very 
close to what's actually done and spec'ed anyway)

I wish to point out that apparently iframe.contentWindow does break 
quite a lot of "eternal invariants" [7] which isn't really good news, 
because it questions their eternity.

Among alternatives I'm thinking of:
* define a new type of proxies for which the target can be changed 
(either only as a spec device of as an actual object that can be 
instantiated in scripts)
* change the behavior of WindowProxy instances when it comes to doing 
things that would commit them to eternal invariants to throw instead of 
forwarding. This solution may still be possible, because it's unlikely 
that Object.defineProperty is widely used in web content today. But this 
change should happen pretty fast before content relies on it.

David

[1] 
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0188.html
[2] 
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0266.html
[3] 
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html
[4] http://davidbruant.github.com/iframeProxyIssueDemo/
[5] 
https://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html
[6] https://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html
[7] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html