On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky <[email protected]> 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
