A DOM use case that can't be emulated with direct proxies
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 
But it won't be possible to do this with the new design, because of
I recommend staying away from Proxy.create as it's likely to not appear
in the spec and be removed from implementations.
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.
> On Wed, Dec 12, 2012 at 2:19 PM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
> A good question by Anne van Kesteren  followed by good remarks
> by Boris Zbarsky  made me try a little something .
> 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
> 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
> 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 , 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"  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.
>  http://davidbruant.github.com/iframeProxyIssueDemo/
>  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>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss