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

Re: @@symbol hooks and cross domain frames

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Thu, 09 Jul 2015 17:22:31 -0400
Message-ID: <559EE617.5070205@mit.edu>
To: Adam Klein <adamk@google.com>
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 7/9/15 5:16 PM, Adam Klein wrote:
> What would HTML say about @@isConcatSpreadable on a same-origin window,
> though?

I assume absolutely nothing, I would think.  Which means it would end up 
defaulting to undefined, unless a page deliberately sets it up on the 
window or somewhere up its prototype chain.

> I had been imagining the solution might be to add an
> [Unforgeable] @@isConcatSpreadable property to Window

Why do we want to prevent people opting same-origin windows into being 
concat-spreadable if they want to?

>     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.

Everything on cross-origin windows is on instances.  See the spec 
proposal at https://etherpad.mozilla.org/html5-cross-origin-objects that 
Bobby and abarth and hixie worked out a while back and hixie is working 
on writing up right now (c.f. 

To be clear, my proposals for what to do with @@isConcatSpreadable and 
@@toStringTag assume that browsers are implementing what that etherpad 
says; they're quite simple to do in that world.

Received on Thursday, 9 July 2015 21:23:05 UTC

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