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

Brendan Eich brendan at mozilla.org
Wed Dec 12 12:10:58 PST 2012


Alex Russell wrote:
> 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.

Having a stable object identity for the window proxy, while navigating 
the window through a series of page loads, requires this wart or an 
equivalent one. Browsers came to this design the hard way. Without the 
window proxy, with only one global object exposed (not just on the scope 
chain), insecurity or else inefficiency ensues.

You could say the wart is having a stable object identity for an object 
that proxies to more than one object over time (but not two at the same 
time).

That is plausible, except that this use-case looks a lot like a membrane 
use-case. Is there anything in the membrane literature where the 
membrane wraps different objects over its lifetime?

/be

>
> 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
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss


More information about the es-discuss mailing list