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 true. > > 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. Agreed. - Adam
Received on Thursday, 9 July 2015 21:16:49 UTC