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

Brandon Benvie brandon at brandonbenvie.com
Wed Dec 12 11:30:28 PST 2012

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.


On Wed, Dec 12, 2012 at 2:19 PM, David Bruant <bruant.d at 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 at mozilla.org
> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/1edf844d/attachment.html>

More information about the es-discuss mailing list