[Flame 2.0] Degraded Geolocation accuracy with Wifi Only

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
4 years ago
3 years ago

People

(Reporter: kglazko, Unassigned)

Tracking

unspecified
x86
Mac OS X

Firefox Tracking Flags

(b2g-v2.0 affected, b2g-v2.1 ?)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Comment 1

4 years ago
Build I.D. 20140805000238
User Branch 2.0
Whiteboard: [perf-reviewed]
Chris - The jumpyness sounds like a geolocation bug to me. Can you confirm?
Flags: needinfo?(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?
Blocks: 1033669
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
Whiteboard: [perf-reviewed]
Kate: does your Flame have QC RIL or MozRIL? If you are using Mozilla builds, I assume MozRIL?
Flags: needinfo?(kglazko)

Comment 5

4 years ago
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
Flags: needinfo?(gkeeley)
(Reporter)

Comment 6

4 years ago
(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.
Flags: needinfo?(kglazko)

Comment 7

4 years ago
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

3 years ago
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.