W3C home > Mailing lists > Public > public-geolocation@w3.org > July 2008

Re: Geolocation API draft updated

From: Andrei Popescu <andreip@google.com>
Date: Mon, 7 Jul 2008 21:02:51 +0100
Message-ID: <708552fb0807071302x56282f05xd4a8b450852002e2@mail.gmail.com>
To: Aza <aza@mozilla.com>
Cc: "public-geolocation@w3c.org" <public-geolocation@w3c.org>

Hi Aza,

Thanks for the comments!

On Fri, Jul 4, 2008 at 1:28 AM, Aza <aza@mozilla.com> wrote:
> Hi Andrei,
> Excellent work putting together this proposal.
> My first concern is the synchronous nature of lastPosition. This is one of
> those cases where API design directly influences the interface. E.g., what
> happens when a website requests geolocation via lastPosition data but does
> not yet have permission? Because this is synchronous, it must block as it
> waits for the permision UI to return. From the Firefox UI standpoint, a
> blocking/modal UI isn't acceptable -- it disrupts the users train of
> thought, forces them to make a decision they may not care about, and doesn't
> work as a security feature since users will habituate to slimply hitting
> "OK"[1].

Sure, that's a very good point.

> The solution, I think, is using an asynchronous method for getting the
> lastPosition. That way, waiting for the secuirty UI is exactly like waiting
> for a slow location service. I propose something like: getLastPosition(),
> which takes exactly the same arguments as getCurrentPosition (so either a
> PositionCallback or a PositionOptions). The other method is to add a
> "lastPosition:true" to the PositionOptions and pass that into
> getCurrentPosition.

I think there is a third option here:
navigator.geolocation.lastPosition could simply be null until the user
has granted the appropriate permissions. What do you think?

Many thanks,
Received on Monday, 7 July 2008 20:03:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:51 UTC