1026115 - geolocation can report inaccurate estimates after gps lock

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Ben Kelly [:bkelly, not reviewing]]

On my v2.0 flame device I sometimes see my position in Here Maps do the following:

1) Give me a course estimate of my location with wide green circle
2) Update over several seconds to refine my location with shrinking green circle
3) Suddenly jump to a completely different location with very poor accuracy (huge green circle).  I believe this location is what IP-based geo gives.
4) Return to accurate location with small green circle.

As a user this is a bit disconcerting and reduces trust in the measurements.

I assume what is going on is that we have racing processes between GPS and MLS/IP-based location.

I haven't looked at the code, but would it be possible to throw out location events according to one of these rules?

a) Ignore location events that are less inaccurate for X seconds after receiving a previous location event.
b) Ignore location changes that are less accurate than last event and move the current location greater than X distance away, for Y seconds after last location event.

The idea with these two rules is once you receive a gps lock the device is going to tend to keep the gps lock with only minor changes to location and accuracy.

Essentially, it seems like we might want some heuristic to de-bounce location information coming from multiple sources simultaneously.

(Or, is something else broken on my device?)

Comment 1

[:garvan]

There are few bugs that have been addressing this. The first is
https://bugzilla.mozilla.org/show_bug.cgi?id=996998
But this should be in the 2.0 build.

Additional guards against jumping are coming:
https://bugzilla.mozilla.org/show_bug.cgi?id=1018379

Comment 2

[Ben Kelly [:bkelly, not reviewing]]

It appears bug 1018379 has been uplifted to aurora which is what I am running.  I *think* I saw had that fix when I saw this happen last, but I will update and try to reproduce again.

Thanks for the info!

Comment 3

[Ben Kelly [:bkelly, not reviewing]]

I definitely am still seeing jumping.  I am on v2.0 pvt which comes from aurora.  I just saw it and my buildid is 20140616160201.  So I believe I am seeing the jumping with bug 996998 and bug 1018379.

Comment 4

[Ben Kelly [:bkelly, not reviewing]]

After observing this for the last few weeks, here is a proposed algorithm to filter reported positions.

1) Keep a "last reported position" value in memory.
2) Just before reporting a position from gecko to content compare with this position.
3) If: a) the accuracy of the new position is worse than accuracy of the last position
   AND b) the distance to the new position from old position is less than the accuracy of the new position
   THEN ignore the new position.  Report nothing.
4) Otherwise notify content and update the "last reported position" value.

The idea her is basically to suppress worse results that are indistinguishable from the last known position.  If we can't tell the two apart, why report a worse value?

Of course if the user legitimately moves, then the distance check will eventually fail and you'll get the new position.

Chris, what do you think of this approach?  Do we already try to do something like that?

Comment 5

[:garvan]

Fully agree! For the non-GPS case we have bug 1018383, which solves similar problems for network location queries. 
What you are seeing is what I see happen without that patch, but that is the no-GPS case.

It would be interesting to see if the bug happens after 1018383 lands. 

From the original description I am not sure you are getting GPS lock. In the developer menu, if you turn on geolocation debugging, you can see what is happening using ADB. This will filter the network requests only adb logcat | grep WIFI
Not sure what to grep to see network+GPS in the log, don't have a device with a GPS in front of me ATM.

Comment 6

[Chris Peterson [:cpeterson]]

Ben: That's a good suggestion. Garvan implemented a similar strategy in bug 996998, but we should be smarter about reporting location changes on all platforms. I filed bug 1036258 to track the suggestion.

Garvan: how does this bug differ from bug 996998?

Comment 7

[:garvan]

Once I get logs, I'll be able to answer. What is described here could be bug 1018383 also. Without logging I'd be guessing. 
I am looking forward to getting off Dolphin and onto the Flame, when I get hands-on with this I'll know pretty quickly what is happening.

Comment 8

[:garvan]

We now have bug 1018383 and various other cache logic bits that have been added over the last while to address this.

(In reply to Ben Kelly [:bkelly] from comment #4)
> 1) Keep a "last reported position" value in memory.

This has always been present, but there were various bugs with this last position that have since been fixed.

> 3) If: a) the accuracy of the new position is worse than accuracy of the
> last position
>    AND b) the distance to the new position from old position is less than
> the accuracy of the new position
>    THEN ignore the new position.  Report nothing.
> 4) Otherwise notify content and update the "last reported position" value.

That is an interesting use case, but is application specific and the content should handle it. Accuracy and distance metrics are extremely inaccurate, and showing the most recent valid GPS info trumps this in all cases. (Note: We have logic in the network geolocation that addresses this for wifi+cell lookups.)

> The idea her is basically to suppress worse results that are
> indistinguishable from the last known position.  If we can't tell the two
> apart, why report a worse value?
 
> Of course if the user legitimately moves, then the distance check will
> eventually fail and you'll get the new position.

The jumping you saw should no longer happen, and part of that fix was a distance check in the network location vs. GPS location.

> Chris, what do you think of this approach?  Do we already try to do
> something like that?

The network location provider has logic to not ask for a known worse position. Based on the information available to that provider, we can determine this. There are fixes to ensure the GPS is used instead of the network provider when it is available, which solves most jumping. Other than that, there isn't any logic to determine the quality of the GPS response.