[whatwg] Location object identity and navigation behavior

[Ian Hickson]

On Tue, 20 Nov 2012, Bobby Holley wrote:
> On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson <ian at hixie.ch> wrote:
> >
> > In thinking about this further last night, it struck me that while the 
> > proposed proxy mechanism was IMHO overly complex, there might be a 
> > simpler mechanism that still gets all the compatibility needs, and 
> > works for Mozilla, and isn't quite so crazy. I'm not a huge fan of 
> > this, but I'd be interested in what Adam thinks of it.
> >
> > Right now, as specced, each Document gets a Location object, but they 
> > all act the same: they all work on the active document and they all do 
> > security checks based on the active document, not the Location's 
> > Document.
> >
> > But what if, instead, we had one Location per Document, and it worked 
> > on that Document (not the active document), with the security policy 
> > being like Window, specific to its Document's effective origin, but 
> > instead of ever getting references to it, you only got references to a 
> > proxy that acted on the active document's Location?
> 
> Wouldn't this effectively mean having a LocationProxy, just like 
> WindowProxy?

Yes. It differs from the original proposal in that there's multiple 
underlying objects and they're just proxied, not just one object that has 
its prototype and properties changed when the history is traversed.


> I'm certainly all for it, and think that it makes things much more sane, 
> though I don't understand why this wouldn't "propagate the magic" that 
> Adam doesn't want to propagate. I might be misunderstanding you though. 
> Can you clarify?

I agree that it does seem to be still more complicated than is apparently 
necessary, at least for implementations where determining the calling 
script's effective script origin is relatively easy.

My understanding is that WebKit, old Gecko, and new IE do what the spec 
says currently, and old IE, Opera, and new Gecko do the proxying model.

For authors, I don't really see the value of the proxying model. The 
current spec model is slightly simpler for authors, but only slightly, 
because you still can't access your own shims when the page is navigated 
to another origin.

For implementors, I'm not really comfortable picking one side or the other 
here. I'm even less comfortable picking what's easy for Chrome over what's 
easy for Gecko. Browsers seem to be changing in both directions, and right 
now seem to be exactly equally split.

So, I dunno. If it's a bust for authors, a tie for browsers, I guess the 
next level is spec writers, and, well, not changing anything is easier 
than changing something, so I guess that argues for not changing it?

I've left the spec as-is for now, but I don't have a good argument one way 
or the other. Sorry for this unsatisfying answer.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'