Geolocation and the Mac

[Doug Turner]

In Bug 874587, we are considering using Core Location as the default
geolocation provider on the Mac. This would replace the use of the
NetworkGeolocationProvider (that currently points to GLS). After code
reviews, we plan to enable this on Nightly and see how it goes.

On Android, we already due use the system location provider and not the
NetworkGeolocationProvider... so this isn't something unexpected.

The main difference is that you will get one prompt from the OS the
first time you use geolocation from Firefox -- just like every other
standard Mac application.

Does anyone have any concern that is specific to change from the
NetworkGeolocationProvider to a Mac platform specific one?

[Justin Dolske]

On 5/21/13 4:45 PM, Doug Turner wrote:

> The main difference is that you will get one prompt from the OS the
> first time you use geolocation from Firefox -- just like every other
> standard Mac application.

Could be a little odd, but as long as it comes up after our own
permission dialog it should be ok.

I was curious if Safari was pre-cleared for this or not. Looks like it
isn't -- I triggered geolocation from maps.google.com, then I got
Safari's prompt for the page, and then an OS prompt regarding Safari was
presented. Nice that they're playing by their own rules. :)

But, hmm... Slightly worrysome -- I clicked "don't allow", and now I
can't get Safari's geolocation to work. It's own dialog comes up, but I
never get the OS prompt again (even after restarting the app).

Yikes, this is crappy. The OS only asks once, and then your choice is
(permanently?) stored in Preferences --> Security & Privacy --> Location
Services. I had to google to find this, as Safari just silently passes
on a failure to the site. I seriously wonder if we should have some UI
(notification bar?) to note when Core Location fails (and send the user
to a SUMO page explaining how to reenable it).

Do the Core Location APIs provide a unique error code for when the
user/OS has blocked permission?

Justin

[Axel Hecht]

Asking the other way around, why are we doing this? Ad hoc it just looks
like more code to maintain.

Also, is there documentation on how the mac does geo location?

We also make statements about our requirements on 3rd party location
services in https://www.mozilla.org/en-US/legal/privacy/firefox.html.
Depending on how mac locates, those may or may not hold?

Axel

[Doug Turner]

> Asking the other way around, why are we doing this? Ad hoc it just looks
> like more code to maintain.

We have been moving to system services where possible. We already did
this on the Android. System service have a much better opportunity to
already have location data allowing us to avoid a trip to GLS

> Also, is there documentation on how the mac does geo location?

Yes.

> We also make statements about our requirements on 3rd party location
> services in https://www.mozilla.org/en-US/legal/privacy/firefox.html.
> Depending on how mac locates, those may or may not hold?

This is not a 3rd party location service. This is part of the Core APIs
of the operating system. The privacy policy may need to be modified
before this change hits beta. I have already notified legal about the
possiblity of this change.

Doug

[Doug Turner]

Justin Dolske wrote:

> Yikes, this is crappy. The OS only asks once, and then your choice is
> (permanently?) stored in Preferences --> Security & Privacy --> Location
> Services. I had to google to find this, as Safari just silently passes
> on a failure to the site. I seriously wonder if we should have some UI
> (notification bar?) to note when Core Location fails (and send the user
> to a SUMO page explaining how to reenable it).

We are doing exactly what Safari and other geolocation-enabled
applications are doing.

The Mac has a system where by location services for all apps are managed
in a central place. We do not work in that system -- we do something
different. This makes a user's view of how their location information
is being share not complete. :( And we should change that.

>
> Do the Core Location APIs provide a unique error code for when the
> user/OS has blocked permission?

We know if the access to CoreLocations was denied. I am not sure if we
can prompt the user again for permission if it was denied in the past.
And if we could, I am not sure I would. What do you think dolske?

Doug

[Justin Dolske]

On 5/22/13 9:49 AM, Doug Turner wrote:

> The Mac has a system where by location services for all apps are managed
> in a central place. We do not work in that system -- we do something
> different. This makes a user's view of how their location information
> is being share not complete. :( And we should change that.

Agreed, I think better integration with OS-provided services is
generally a swell thing. It just brings a bit of UX complexity in this case.

>> Do the Core Location APIs provide a unique error code for when the
>> user/OS has blocked permission?
>
> We know if the access to CoreLocations was denied. I am not sure if we
> can prompt the user again for permission if it was denied in the past.
> And if we could, I am not sure I would. What do you think dolske?

We don't need to trigger the OS prompt again, just provide some info to
the user to help them understand why Firefox's geolocation isn't working.

The specific concern is that users won't understand that the one-time OS
prompt can permanently block the browser's geolocation ability on all
sites. The way Safari works is especially confusing -- the app will
still prompt the user for permission on a site, but then the OS blocks
the request. And so it seems like Safari is broken. (Of course if the
user denies the browser's per-site prompt, this problem doesn't arise.)

So, either (1) the browser's prompt should shown with some help for the
"you told us 'yes' but told the os 'no' make up your mind" case, or (2)
the browser's prompt should never be shown when the the OS won't let it
work anyway. I don't think #2 is a good choice, because it feels more
like a silent accidental failure mode than a solid indication of user
intent.

Justin