Re: Cross-origin windows and how to explain them in ECMAScript semantics

Le 10/02/2014 17:42, Tom Van Cutsem a écrit :
> Hi David,
>
> 2014-02-08 13:16 GMT+01:00 David Bruant <bruant.d@gmail.com 
> <mailto:bruant.d@gmail.com>>:
>
>     [...]
>     The particularly tricky case is the combination of:
>     1) from the parent, iframe.contentWindow and the global object of
>     the iframe are the same object (=== observable after they become
>     same-origin). This seems to be required for web-compatibility
>     2) The .close function each side can [[Get]] is a different value
>     [1] (but remains the same if [[Get]] several times from the same
>     context).
>
>     This is supposed to be impossible in naīve ES semantics since the
>     same object will always return the same value for a property. This
>     is less true with getters and proxies, but even then, they can't
>     decide what to return based on who is asking (because they're not
>     supposed to have access to such an information).
>
>     However, I think that this behavior can be explained if the parent
>     and the iframe are in two sides of a slightly modified dry/wet
>     membrane [2].
>     In effect, the WindowProxy seen on each side of the iframe would
>     be two different objects, but the scripts in each membrane could
>     never observe it. However, based on which side of the membrane is
>     asking (the handler knows if the proxy is wet or dry), a
>     observably different close function can be returned.
>
>     Does this sound like a possible explanation of the attempted spec
>     behavior? (obviously even if it is, it doesn't need to be spec'ed
>     or implemented as such)
>
>
> It does to me. Is the .close property observable as configurable:true? 
> If so, then I don't see any conflict with ES6 semantics.
Yes. It's been in discussion at some point, but I think now, everyone 
agrees on observing configurable:true (with partial configurable:false 
behavior for some properties).

Thanks for your response, Tom!

David