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

Alex Russell slightlyoff at google.com
Wed Dec 12 11:44:55 PST 2012

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 <bruant.d at gmail.com<javascript:_e({}, 'cvml', '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.
> David
> [1]
> http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#the-window-object
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/84bef237/attachment.html>

More information about the es-discuss mailing list