Alex Russell wrote:
Window interceptors (as we call them in the browser world) are simply nuts. We simply shouldn't be terribly interested in re-creating this wart.
Having a stable object identity for the window proxy, while navigating the window through a series of page loads, requires this wart or an equivalent one. Browsers came to this design the hard way. Without the window proxy, with only one global object exposed (not just on the scope chain), insecurity or else inefficiency ensues.
You could say the wart is having a stable object identity for an object that proxies to more than one object over time (but not two at the same time).
That is plausible, except that this use-case looks a lot like a membrane use-case. Is there anything in the membrane literature where the membrane wraps different objects over its lifetime?
/be
On Wednesday, December 12, 2012, David Bruant wrote: Le 12/12/2012 20:29, Kevin Reid a écrit :On Wed, Dec 12, 2012 at 11:19 AM, David Bruant <[email protected] <javascript:_e({}, 'cvml', '[email protected]');>> wrote: 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 bumped into this myself just recently while attempting to implement virtualized navigable iframes in Caja — I need to emulate exactly this behavior.Do you have a pointer to the code for that, just out of curiosity?[...] 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. Indeed! 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. The best option I see at the moment would be that a WindowProxy refuses to commit, but a Window does. That is, code operating on 'window' within the iframe can still Object.defineProperty, but from the outside every property of Window appears to be configurable. This is what I have implemented in my current draft.Let's say that the window has a non-configurable, non-writable property, what happens to Object.getOwnPropertyDescriptor on the WindowProxy? Does it throw? (I would be fine with this behavior, but I'm just wondering)On the other hand, it seems that in browsers either 'window' is also the same (!) proxy, or === invariants are broken, or the WindowProxy is acting as a membrane: > f.contentWindow === f.contentWindow.window trueI think it's a membrane. The HTML5 spec [1] makes pretty clear that the window property isn't a Window, but a WindowProxy. HTML5 experts will know better, but I think no one ever manipulates directly a Window instance, there is always a WindowProxy mediating the access. Of course, the implementation is free to optimize this mediation. David [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
