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

Kevin Reid kpreid at google.com
Wed Dec 12 13:30:57 PST 2012

On Wed, Dec 12, 2012 at 1:23 PM, David Bruant <bruant.d at gmail.com> wrote:

>  Le 12/12/2012 21:42, Kevin Reid a écrit :
>  Exactly. So a user-defined switching proxy needs only to:
> 1. refuse to commit to any invariant (non-configurable property or
> preventExtensions)
> 2. even if its switchable-target has an invariant, do not expose that
> invariant (i.e. pretend each property is configurable)
> Pretend that something non-configurable actually is configurable is an
> invariant violation. To be more concrete:
> * There is an webpage with an iframe
> * The same window object is proxied by 2 WindowProxy instances. One
> outside the iframe, one inside.
> * Inside of the iframe, scripts can add a non-configurable property
> "azerty" to their global.
> * Outside the iframe, what happens when
> Object.getOwnPropertyDescriptor(iframeWindow, 'azerty') is called?
> You're suggesting that {configurable: true} is returned. The problem is
> that on the actual Window instance, there is a non-configurable property,
> so if the WindowProxy handler tries to do that, an error will be thrown
> because of invariant checks.

The JS runtime won't know that the proxy has anything to do with the actual
Window instance. The Proxy's formal target will be just {}; only the
handler interacts with the Window. This is the distinction I meant but did
not state clearly by saying “switchable-target” as opposed to proxy-target.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/c625cd4f/attachment-0001.html>

More information about the es-discuss mailing list