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

Kevin Reid kpreid at google.com
Wed Dec 12 11:49:23 PST 2012


On Wed, Dec 12, 2012 at 11:39 AM, David Bruant <bruant.d at gmail.com> 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>wrote:
>
>> 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 haven't made it public yet, but it's just the obvious implementation of
an (old-style, as implemented in Firefox/Chrome) proxy with a switchable
“target”.

>  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)
>

It returns a descriptor which is identical except that it claims to be
configurable. Attempting to actually reconfigure it using defineProperty
would throw.

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

The disturbing thing about "window instanceof WindowProxy", if you will,
(given that it accurately reports its mutability) is that since window is
the global environment, it means that the global environment cannot have
immutable things. Of course, SES actually establishes a new environment
(using 'with') for secured eval.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/bb0f10f9/attachment-0001.html>


More information about the es-discuss mailing list