W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Location object identity and navigation behavior

From: Bobby Holley <bobbyholley@gmail.com>
Date: Mon, 7 Jan 2013 17:39:12 -0800
Message-ID: <CAKBxTcJ1+a-145ivT4OJvZg7eAR3fNvi1EU069axXdyGnvFg9A@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: whatwg <whatwg@lists.whatwg.org>, Matt Wobensmith <mwobensmith@mozilla.com>, Boris Zbarsky <bzbarsky@mit.edu>, Adam Barth <w3c@adambarth.com>, Johnny Stenback <jst@mozilla.com>
On Mon, Jan 7, 2013 at 12:26 PM, Ian Hickson <ian@hixie.ch> wrote:

> 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.
>

Given the concerns in this thread, I never landed such a change to Gecko.
New Gecko == Old Gecko here.


>
> 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.
>

I still think it's less confusing for the casual author (since, like
window, if the object describes the picture frame, there would appear to be
one object per picture frame), though for spec-reading authors the extra
LocationProxy stuff might be more confusing.


> 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.
>

No worries - I appreciate the thoroughness of consideration you've given
here. And anyways, I managed to get rid of most of the nastiest stuff in
Gecko's Location implementation, in exchange for explicit security checks
in each C++ method implementation. Aside from concerns about stack
introspection, the main downside of this approach is that it's a blacklist,
rather than a whitelist (like our other security code), so we'll have to be
extra careful when implementing anything new on Location. Please keep that
in mind when updating the spec. ;-)

Cheers,
bholley
Received on Tuesday, 8 January 2013 01:39:59 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT