W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2014

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

From: David Bruant <bruant.d@gmail.com>
Date: Mon, 10 Feb 2014 17:45:48 +0100
Message-ID: <52F9023C.6090700@gmail.com>
To: Tom Van Cutsem <tomvc.be@gmail.com>
CC: "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>, Bobby Holley <bholley@mozilla.com>
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!

Received on Monday, 10 February 2014 16:46:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:19 UTC