A DOM use case that can't be emulated with direct proxies

Alex Russell slightlyoff at google.com
Wed Dec 12 11:56:54 PST 2012


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 <bruant.d at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/c7678e35/attachment.html>


More information about the es-discuss mailing list