[whatwg] Location object identity and navigation behavior

[Adam Barth]

On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley <bobbyholley at 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