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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to