W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2015

Re: @@symbol hooks and cross domain frames

From: Adam Klein <adamk@google.com>
Date: Thu, 9 Jul 2015 14:16:21 -0700
Message-ID: <CAEvLGcK2ru43pKcLLG6GHXkBTZ5=MPbGD6zR4KUVbPTA506Orw@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: Erik Arvidsson <arv@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, Caitlin Potter <caitpotter88@gmail.com>, Allen Wirfs-Brock <allenwb@mozilla.com>, Brian Terlson <brian.terlson@microsoft.com>, Bobby Holley <bholley@mozilla.com>
On Thu, Jul 9, 2015 at 11:53 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 7/9/15 9:47 AM, Erik Arvidsson wrote:
>> In ES5 the following works:
>>    [].concat(windowFromOtherDomain)
>> But in ES6 it fails because reading @@isConcatSpreadable throws an
>> access denied error.
> Good catch.
> We should consider just making @@isConcatSpreadable on a cross-origin
> window work and return undefined.  This doesn't require any chances to ES,
> just to the DOM-defined behavior of cross-origin windows, and should give
> us the desired behavior, right?

What would HTML say about @@isConcatSpreadable on a same-origin window,
though? I had been imagining the solution might be to add an [Unforgeable]
@@isConcatSpreadable property to Window; the only downside is that this
would disallow same-origin windows from setting @@isConcatSpreadable to

>  Similar issues arise with @@toStringTag and @@hasInstance
> I think @@toStringTag should also simply return undefined on a
> cross-origin window.  This will give us the desired behavior of "[object
> Object]".

This works a little better, in that window will have a @@toStringTag
property somewhere on its prototype chain, but it would actually need to be
on instances to return undefined before the security check kicks in.

> @@hasInstance can just throw; I can't see any use cases for having a
> cross-origin window on the _right-hand_ side of instanceof, which is where
> the @@hasInstance call happens.

Thanks for pointing this out, I agree that this is not problematic (in fact
it already throws, since window and location instances are not functions).

>  There might also be similar issues with Get(x, "constructor") and
>> @@species but I believe all of them might be better of throwing.
> I think throwing for those is eminently reasonable.


- Adam
Received on Thursday, 9 July 2015 21:16:49 UTC

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