- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 08 Nov 2012 22:21:22 -0800
- To: Adam Barth <w3c@adambarth.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Bobby Holley <bobbyholley@gmail.com>, Johnny Stenback <jst@mozilla.com>
On 11/8/12 6:09 PM, Adam Barth wrote: > I don't think I quite understand what you mean, but the way this works > in WebKit is that each Window object has its own Location object. That's not how it works in Presto and Trident, as far as we can tell based on testing with "==". In those, each WindowProxy has its own Location object. > The location object operates on the current Window for the WindowProxy. Yes. _That_ all browsers are consistent on, and is totally not what the spec says right now. In the spec, there is one Location per Window, and the object operates on the Window it's associated with. The fact that this does not match any browsers is what makes us suspect the spec is not web-compatible. > In WebKit at least, it would be a security vulnerability to expose > JavaScript objects that belong to Document B to Document A because > that would give Document A access to the prototype objects for > Document B. You presumably have a solution for this situation for the WindowProxy case, right? Certainly Gecko does, and we would be using the same solution for Location if we tie the lifetime of a Location to the lifetime of a WindowProxy. -Boris P.S. I'll leave it to Matt and Bobby to answer your question about your testcase with function f(), because while I suspect I know what UAs do there in practice there is no way to tell without actually testing...
Received on Friday, 9 November 2012 07:17:26 UTC