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.
Build I.D. 20140805000238 User Branch 2.0
Chris - The jumpyness sounds like a geolocation bug to me. Can you confirm?
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?
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → ?
Flags: needinfo?(cpeterson) → needinfo?(gkeeley)
Summary: [Flame 2.0] Degraded Geolocation Performance with Wifi Only → [Flame 2.0] Degraded Geolocation accuracy with Wifi Only
Kate: does your Flame have QC RIL or MozRIL? If you are using Mozilla builds, I assume MozRIL?
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
(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.
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).
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.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.