1049016 - [Flame 2.0] Degraded Geolocation accuracy with Wifi Only

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: FindMyDevice, defect)

Description

[Kate Glazko]

STR:
- Remove Sim Card from phone
- Enable Wifi (in my case, I'm using a pretty good network here at Mozilla)
- Sign into FxA/ enable FMD
- Go onto FMD website
- Device should be located

Expected: Location should vary, but should remain somewhat consistent.

Actual: Location is switching every few seconds, appears to be more inconsistent than I've ever experienced during testing. It appears to remain in Mountain View, but has jumped all the way to Palo Alto and Sunnyvale at some points.

Comment 1

[Kate Glazko]

Build I.D. 20140805000238
User Branch 2.0

Comment 2

[Jason Smith [:jsmith]]

Chris - The jumpyness sounds like a geolocation bug to me. Can you confirm?

Comment 3

[Chris Peterson [:cpeterson]]

Garvan: this problem sounds like the device is falling back to GeoIP. When does Gecko's geo stack allow a recent-but-less-accurate position (GeoIP) to override a older-but-more-accurate position (Wi-Fi) in B2G 2.0?

Comment 4

[Chris Peterson [:cpeterson]]

Kate: does your Flame have QC RIL or MozRIL? If you are using Mozilla builds, I assume MozRIL?

Comment 5

[:garvan]

1) Can we get a log with geolocation debugging turned on?
2) Can this be repro on 2.1 (m-c)?


comment 3: The NetworkGeolocationProvider.js will not fall back to GeoIP ever (until it is shutdown), once it has a better location.
This bug is on the Flame (which has GPS, and rarely would use a network location), and the only code that combines Network and GPS logic is:
GonkGPSGeolocationProvider::NetworkLocationUpdate::Update(nsIDOMGeoPosition *position)
and it will only use network location if the gps hasn't responded in 10s

Comment 6

[Kate Glazko]

(In reply to Chris Peterson (:cpeterson) from comment #4)
> Kate: does your Flame have QC RIL or MozRIL? If you are using Mozilla
> builds, I assume MozRIL?

From what I know, MozRIL.

Comment 7

[:garvan]

Unfortunately, 2.0-only + non-QC geo bug is not actionable -by policy, not by my choice :).
Perhaps this bug can be rechecked on any other branch than 2.0 with mozilla built code, or rechecked on a QC 2.0 build.

(There is a chance bug 1033274 would fix this, due to logic cleanup that happened, but that won't ever land on 2.0 -it will land on 2.0M though).

Comment 8

[Hanno Schlichting]

The hardware/software combination this was observed on is unsupported. Since we haven't gotten any update on this anymore, I'm assuming this got fixed or is not present on supported devices.