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

David Bruant bruant.d at gmail.com
Wed Dec 12 11:51:10 PST 2012


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 <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/6e6273f4/attachment.html>


More information about the es-discuss mailing list