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

Kevin Reid kpreid at google.com
Wed Dec 12 11:29:15 PST 2012


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.


> [...] 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.

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

This would seem to prohibit the distinction I propose.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/d61307d7/attachment-0001.html>


More information about the es-discuss mailing list