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.
David
[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 <[email protected]
<mailto:[email protected]>> 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
[email protected] <mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
