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.
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 > true > > I 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
