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

[David Bruant]

Le 12/12/2012 20:49, Kevin Reid a écrit :
> On Wed, Dec 12, 2012 at 11:39 AM, David Bruant <bruant.d at gmail.com 
> <mailto: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 <mailto: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”.
Interesting. As I said, target-switching won't be possible in direct 
proxies.

>>     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.
Direct proxies invariant checks would make such a "lie" about 
configurability impossible. The engine would throw if you try to pretend 
a non-configurable property is configurable. See 
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#invariant_enforcement 


> 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.
One idea would be that different handlers are used based on the context. 
Different handlers would encode whether to create non-configurable 
properties.
If the WindowProxy instance has been obtained through accessing the 
global of your environement, you can add non-configurable properties.
If the WindowProxy has been obtained with iframe.contentWindow then you 
can't create non-configurable properties.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121212/1bef1cd1/attachment.html>