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

David Bruant bruant.d at gmail.com
Wed Dec 12 11:39:36 PST 2012

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 
> <mailto: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 
> '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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/67ff7a17/attachment.html>

More information about the es-discuss mailing list