Yep. On Wednesday, December 12, 2012, David Bruant wrote:
> Le 12/12/2012 20:44, Alex Russell a écrit : > > 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. > > I'm not sure I understand your point. Do you mean that emulating them in > pure ECMAScript should be an exception to the "emulate DOM" proxy use case? > > David > > > 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 <bruan...@gmail.com>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 > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss