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

David Bruant bruant.d at gmail.com
Wed Dec 12 11:46:59 PST 2012

With the previous proxy design indeed. I see you're using Proxy.create [1]
But it won't be possible to do this with the new design, because of 
invariant enforcement.

I recommend staying away from Proxy.create as it's likely to not appear 
in the spec and be removed from implementations.


[1] https://github.com/appjs/appjs/blob/master/lib/handlers.js#L21

Le 12/12/2012 20:30, Brandon Benvie a écrit :
> 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 <bruant.d at gmail.com 
> <mailto: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
>     [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
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/25a595e9/attachment.html>

More information about the es-discuss mailing list