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
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
