- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Thu, 09 Jul 2015 17:22:31 -0400
- 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. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=20701>). 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. -Boris
Received on Thursday, 9 July 2015 21:23:05 UTC