1336245 - Geolocation should return available low-res location when high-res location is not yet available

Status: NEW

(Core :: DOM: Geolocation, defect, P2)

Description

[Thomas Wisniewski]

m3.barebackrt.com seems to always time out on geo-location, getting back "Position acquisition timed out". This happens on multiple different Android devices of varying OSes. On those same devices, Chrome fetches the location almost instantly.

I have tested in Firefox 50.1.0 and 54/nightly with the same results: the permissions prompt appears, I accept, I see the Location service's activity icon animating at the top of my Android screen (in Android 4), the attempt ultimately times out, then the activity icon vanishes a few seconds later.

Note that one does not have to log in to demonstrate the issue; geolocation is attempted on the login page (see the red text near the bottom of the page, which alters when after a timeout occurs).

Also note that the Android Location service was active and proper permissions were granted to Firefox in all the cases in my own tests.

It does not appear that the code involved [1] does anything particularly fancy:

>navigator.geolocation.getCurrentPosition(geoLocResp, geoLocErrs, {
>    enableHighAccuracy: true,
>    timeout: 10000,
>    maximumAge: 30
>}

[1] https://m3.barebackrt.com/js/geoInfo.js

Comment 1

[Andrew Overholt [:overholt]]

Kan-Ru, can you take a look?

Comment 2

[Kan-Ru Chen [:kanru] (UTC+9)]

I can reproduce locally. I'll investigate this.

Comment 3

[Kan-Ru Chen [:kanru] (UTC+9)]

I think this is somewhat expected since the website is requesting high accuracy location. That forces us to use GPS to acquire locations, that is slow and doesn't work indoors.

Aside from switching to Google Play Services, I'm not sure how to improve this.

Comment 4

[Karl Dubost💡 :karlcow]

Kan-Ru, do you know if Chrome is really sending high accuracy data on this request?
Or does it create a normal response while still working on getting better data in the future?


The specs says:

> The enableHighAccuracy attribute provides a hint 
> that the application would like to receive the best 
> possible results. This may result in slower response 
> times or increased power consumption. The user might 
> also deny this capability, or the device might not 
> be able to provide more accurate results than if the 
> flag wasn't specified. The intended purpose of this 
> attribute is to allow applications to inform the 
> implementation that they do not require high accuracy 
> geolocation fixes and, therefore, the implementation 
> can avoid using geolocation providers that consume 
> a significant amount of power (e.g. GPS). This is 
> especially useful for applications running on 
> battery-powered devices, such as mobile phones. 

What I understand is that 
1. This is a hint
2. "would like" is not a MUST
3. "best possible results" there is possible. 

So I would probably return something before the timeout even if it's not full high accuracy

Comment 5

[Karl Dubost💡 :karlcow]

To further my point.
https://dev.w3.org/geo/api/spec-source.html#requirements_section

There's no requirement on providing highly accurate data, but a requirement on providing the level of accuracy.

also in step 3 of geolocation 
https://dev.w3.org/geo/api/spec-source.html#geolocation_interface

3. Start a location acquisition operation (e.g. by invoking a platform-specific API), possibly taking into account the value of the enableHighAccuracy variable (see the definition of enableHighAccuracy for details).

"Possibly taking into accounts", My interpretation is that if you can't in the given defined timeout, just provide what you can.

Comment 6

[Kan-Ru Chen [:kanru] (UTC+9)]

Yes indeed. It looks like the chromium implementation will report the location in a best effort manner.

Comment 7

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 8

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.

Comment 9

[Adam Stevenson [:adamopenweb]]

Just revisiting this bug, original website issue still exists. Haven't seen reports of similar bugs so far.