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: Tom Van Cutsem <tomvc.be@gmail.com>
Date: Mon, 10 Feb 2014 17:42:31 +0100
Message-ID: <CAKDfNj8ZfX5LBreVE0p5+LQHYzuOT_Jt6hmA3M8w22yff+vY9w@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>, "Mark S. Miller" <erights@google.com>, Bobby Holley <bholley@mozilla.com>
Hi David,

2014-02-08 13:16 GMT+01:00 David Bruant <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.

Received on Monday, 10 February 2014 16:42:58 UTC

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