W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

Re: [whatwg] Location object identity and navigation behavior

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 08 Nov 2012 22:21:22 -0800
Message-ID: <509CA0E2.9050206@mit.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT