This can be handled by proxies and in fact it's something I've done with proxies for App.js for pretty much the same scenario. A single Window object exists for each desktop window created, but the page can be navigated as it does in a browser, wiping out the entire context's object graph. The proxy simply reestablishes a connection with the new JS context upon navigating and changes targets. All the object references to objects from the old JS context (which forms a membrane, as they are all proxies) are neutered at the same time.<div>
<br></div><div>The specified proxy target doesn't correspond to the various context globals; rather it can be used to house expando properties that may be shown on every transitory target object.</div><div><br></div><div>
<a href="https://github.com/appjs/appjs/blob/master/lib/window.js#L35">https://github.com/appjs/appjs/blob/master/lib/window.js#L35</a><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Dec 12, 2012 at 2:19 PM, David Bruant <span dir="ltr"><<a href="mailto:bruant.d@gmail.com" target="_blank">bruant.d@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
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].<br>
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.<br>

I thing this is something that can't be implemented with direct proxies. Is this conclusion shared?<br>
<br>
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.<br>

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:<br>
* Model WindowProxy objects as ES proxies<br>
* 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)<br>
<br>
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.<br>
<br>
Among alternatives I'm thinking of:<br>
* 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)<br>
* 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.<br>

<br>
David<br>
<br>
[1] <a href="http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0188.html" target="_blank">http://lists.w3.org/Archives/<u></u>Public/public-script-coord/<u></u>2012OctDec/0188.html</a><br>
[2] <a href="http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0266.html" target="_blank">http://lists.w3.org/Archives/<u></u>Public/public-script-coord/<u></u>2012OctDec/0266.html</a><br>
[3] <a href="http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html" target="_blank">http://lists.w3.org/Archives/<u></u>Public/public-script-coord/<u></u>2012OctDec/0267.html</a><br>
[4] <a href="http://davidbruant.github.com/iframeProxyIssueDemo/" target="_blank">http://davidbruant.github.com/<u></u>iframeProxyIssueDemo/</a><br>
[5] <a href="https://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html" target="_blank">https://github.com/<u></u>DavidBruant/<u></u>iframeProxyIssueDemo/blob/<u></u>master/index.html</a><br>
[6] <a href="https://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2012-<u></u>September/025243.html</a><br>
[7] <a href="https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html" target="_blank">https://mail.mozilla.org/<u></u>pipermail/es-discuss/2011-May/<u></u>014150.html</a><br>
______________________________<u></u>_________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" target="_blank">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank">https://mail.mozilla.org/<u></u>listinfo/es-discuss</a><br>
</blockquote></div><br></div>