1057076 - GonkGPSGeolocationProvider: enableHighAccuracy is ignored, should be used to avoid enabling the GPS

Status: RESOLVED INVALID

(Core :: DOM: Geolocation, defect)

Description

[:garvan]

The JS PositionOptions in the JS Geolocation API have an arg for enableHighAccuracy true/false.

On B2G devices, if this arg is false, we can just use the network geolocation provider. The question I have, and I think there is a previous bug discussing this which I will xref, is if the highAccuracy is false, and no network location is available, do we really want this to fail? Or should it fallback to trying to get a GPS location? IIRC, the enableHighAccuracy does not mean to disable higher accuracy providers.

Here is the code where this flag is set in the gps provider. We have the flag, it just isn't used yet:
https://mxr.mozilla.org/mozilla-central/source/dom/system/gonk/GonkGPSGeolocationProvider.cpp#836

Comment 1

[Bhavna Sharma]

As per the HTML5 API, this flag is useful for saying that

Comment 2

[Bhavna Sharma]

Sorry about the incomplete comment above:

As per the HTML5 API, this flag is useful for application that are sure that do not want high accuracy fixes, for example like weather apps. And hence can avoid use of providers that will consume a lot of power. Enabling high power providers in this case may not be correct.

Comment 3

[Chris Peterson [:cpeterson]]

What is the application developer's motivation for using enableHighAccuracy = false? They probably want to reduce geolocation latency (for their application's direct benefit) or reduce power usage (as an indirect benefit for the user). They probably don't want to reject high-accuracy results, if network location provider is not available.

Also, getCurrentPosition() and watchPosition() might want to handle enableHighAccuracy differently.

Comment 4

[Chris Peterson [:cpeterson]]

Also, it would be interesting to collect Firefox and B2G telemetry to track the geolocation PositionOptions used by real-world websites and web apps.

Comment 5

[Stephen Li]

I have two comments for location on FFOS,

- Are there any long term plan to supporting higher granularity on location permission control? High accuracy location access usually reveal much more sensitive privacy information of the user. On Android, user can choose to allow high accuracy location access or only coarse location access. If there is long term plan to support this, the design for supporting this would be different because providing high accuracy fix to low accuracy request will violate the API contract.

- We will need to enhance the lower layer to provide best support for using high accuracy location source to support low accuracy request. This will include optimizations for power and time to first fix.

Please let me know the decision here.

Comment 6

[:garvan]

(In reply to Stephen Li from comment #5)
> I have two comments for location on FFOS,
> 
> - High accuracy location access usually reveal much more
> sensitive privacy information of the user.

I don't think privacy is within the scope of this bug. Best to open a separate bug for that (or discuss on B2G mailing list, or on mailing list for w3c geo spec http://dev.w3.org/geo/api/spec-source.html).

> support for using high accuracy location source to support low accuracy request. This will
> include optimizations for power and time to first fix.

If you can be specific as the optimizations you are thinking of we can discuss them before patching starts.

Comment 7

[Chris Peterson [:cpeterson]]

(In reply to Stephen Li from comment #5)
> - Are there any long term plan to supporting higher granularity on location
> permission control? High accuracy location access usually reveal much more
> sensitive privacy information of the user. On Android, user can choose to
> allow high accuracy location access or only coarse location access. If there
> is long term plan to support this, the design for supporting this would be
> different because providing high accuracy fix to low accuracy request will
> violate the API contract.

That's a good point. If an Android app only has permission to request low accuracy fixes and the OS has cached a recent high accuracy fix, Google's Fused Location Provider adds some random noise to to the high accuracy fix before returning it.

AFAIK, we don't have any plans to support higher granularity on location permissions. I don't think we are against the idea, but it would add extra complexity to the UI and implementation. This is more of a "power user" feature and Firefox OS's primary market is for first-time smartphone users who would probably be confused by these settings.

> - We will need to enhance the lower layer to provide best support for using
> high accuracy location source to support low accuracy request. This will
> include optimizations for power and time to first fix.

What are the optimizations for power and TTFF that you would add? Does your lower layer currently try to return the most accurate fix, regardless of power usage or latency?

Our documentation says enableHighAccuracy's default value is false. We could try to do something clever if we treated enableHighAccuracy as a tri-state value: we could differentiate between enableHighAccuracy === false (explicitly set = false by the application developer) and enableHighAccuracy === undefined (default value, unset by application developer). :)

Comment 8

[Stephen Li]

(In reply to Chris Peterson (:cpeterson) from comment #7)
> (In reply to Stephen Li from comment #5)
> > - Are there any long term plan to supporting higher granularity on location
> > permission control? High accuracy location access usually reveal much more
> > sensitive privacy information of the user. On Android, user can choose to
> > allow high accuracy location access or only coarse location access. If there
> > is long term plan to support this, the design for supporting this would be
> > different because providing high accuracy fix to low accuracy request will
> > violate the API contract.
> 
> That's a good point. If an Android app only has permission to request low
> accuracy fixes and the OS has cached a recent high accuracy fix, Google's
> Fused Location Provider adds some random noise to to the high accuracy fix
> before returning it.
> 
> AFAIK, we don't have any plans to support higher granularity on location
> permissions. I don't think we are against the idea, but it would add extra
> complexity to the UI and implementation. This is more of a "power user"
> feature and Firefox OS's primary market is for first-time smartphone users
> who would probably be confused by these settings.

Thanks for the clarification.

> 
> > - We will need to enhance the lower layer to provide best support for using
> > high accuracy location source to support low accuracy request. This will
> > include optimizations for power and time to first fix.
> 
> What are the optimizations for power and TTFF that you would add? Does your
> lower layer currently try to return the most accurate fix, regardless of
> power usage or latency?
> 
> Our documentation says enableHighAccuracy's default value is false. We could
> try to do something clever if we treated enableHighAccuracy as a tri-state
> value: we could differentiate between enableHighAccuracy === false
> (explicitly set = false by the application developer) and enableHighAccuracy
> === undefined (default value, unset by application developer). :)


If the lower layer knows that low accuracy fix is expected, then we don't have to burn power & long time trying to achieve high accuracy fix that usually is expected from GPS. For lower layer to support this, an indicator that this is for "low accuracy" on the HAL API would be good. Then we can decouple the two layers in terms of schedule for implementation. What's the rough time frame for implementation of this patching?

Comment 9

[Bhavna Sharma]

(In reply to Stephen Li from comment #8)

> If the lower layer knows that low accuracy fix is expected, then we don't
> have to burn power & long time trying to achieve high accuracy fix that
> usually is expected from GPS. For lower layer to support this, an indicator
> that this is for "low accuracy" on the HAL API would be good. Then we can
> decouple the two layers in terms of schedule for implementation. What's the
> rough time frame for implementation of this patching?

The HTML5 API already provides a low/high accuracy indicator, I think what Chris is proposing here is an undefined indicator. So first try to get the fix with low power providers, and if that does not work use the high power ones.

Comment 10

[Bhavna Sharma]

Chris, When is this patch planned for ?

Comment 11

[Chris Peterson [:cpeterson]]

Bhavna, this GPS feature is not currently scheduled for any particular B2G release. This bug is mostly a placeholder to preserve this API design discussion. :)