- From: Adam Barth <w3c@adambarth.com>
- Date: Thu, 8 Nov 2012 18:09:54 -0800
- To: Bobby Holley <bobbyholley@gmail.com>
- Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Johnny Stenback <jst@mozilla.com>
On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley <bobbyholley@gmail.com> wrote: > The current spec for the Location object doesn't match reality. At the > moment, the spec says that Location is a per-Window object that describes > the associated Document. However, in our testing, it appears that none of > the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all > implementations of Location describe the active document in the browsing > context (that is to say, the referent of the WindowProxy). This suggests > that the spec's current language is likely not web-compatible. > > If the Location object describes the browsing context, we're left to > consider whether there should be one Location object per Window or one > Location object per browsing context. Gecko and Webkit currently do the > former, and Trident and Presto do the latter (see again [1]). I would like > to change Gecko's behavior here [2], because would simplify a lot of > security invariants and generally make things more sane. How do WebKit > folks feel about this? I'm not sure I quite understand what you mean here. Can you describe an experiment that would distinguish these cases? I looked at [1], but it was too complicated for me to understand quickly. Consider the following case: == Document A == <script> Object.prototype.foo = "A1"; window.location.bar = "A2"; function f() { var loc = window.location; print(loc.foo); // print is a magic function that lets me see this value print(loc.bar); } </script> == Document B == <script> Object.prototype.foo = "B1"; window.location.bar = "B2"; </script> 1) Document A is displayed in browsing context X. 2) Browsing context X is navigated and now displays document B. 3) Function f is called. What values are printed? > If Location follows the WindowProxy, an interesting question is what > happens to expando properties on navigation. I did some testing, and UAs > seem to have pretty inconsistent behavior here [3]. As such, I think the > sanest policy is simply to clear expandos on Location each time the page is > navigated. This is the approach I've taken in the patches in [2]. 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. The location object operates on the current Window for the WindowProxy. 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. Adam
Received on Friday, 9 November 2012 06:50:31 UTC