- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 9 Nov 2012 09:30:31 -0800
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Bobby Holley <bobbyholley@gmail.com>, Johnny Stenback <jst@mozilla.com>
On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > 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. The WindowProxy is a special, magical object because references to it magically change which JavaScript object they refer to over time. If possible, I would like to avoid infecting other objects with its magic. Adam
Received on Friday, 9 November 2012 17:54:15 UTC