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.
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. https://github.com/appjs/appjs/blob/master/lib/window.js#L35 On Wed, Dec 12, 2012 at 2:19 PM, David Bruant <bruan...@gmail.com> wrote: > 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<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<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<http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0267.html> > [4] > http://davidbruant.github.com/**iframeProxyIssueDemo/<http://davidbruant.github.com/iframeProxyIssueDemo/> > [5] https://github.com/**DavidBruant/**iframeProxyIssueDemo/blob/** > master/index.html<https://github.com/DavidBruant/iframeProxyIssueDemo/blob/master/index.html> > [6] https://mail.mozilla.org/**pipermail/es-discuss/2012-** > September/025243.html<https://mail.mozilla.org/pipermail/es-discuss/2012-September/025243.html> > [7] > https://mail.mozilla.org/**pipermail/es-discuss/2011-May/**014150.html<https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html> > ______________________________**_________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss> >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
