Closed Bug 828563 Opened 10 years ago Closed 9 years ago GPS not finding correct location on Galaxy Nexus


(Core :: DOM: Geolocation, defect)

Not set



Tracking Status
firefox20 --- affected
firefox21 --- affected
firefox22 --- affected
firefox23 --- fixed
fennec + ---


(Reporter: krudnitski, Assigned: cpeterson)





(2 files)

Attached image pop-up boxes
go to (and it will direct you to on Fx 18. For the first time, select 'allow' to the 'storing data on your device for offline use' and select 'share / don't ask again for this site' for 'wants your location'.

The GPS doesn't update properly - it is not listing me in my current location, but rather keeps thinking that I am in a location fix I made using Google Maps for Android 3 days ago and I can't get it to update to my current GPS fix.

This application is very important to fix for MWC - it is being used for FFOS and it needs to work as expected on Fx for Android.
What happens if you long-tap on the URL-bar while at HERE Maps and tap 'Site Settings', clear both and try again?
On Chrome, it is finding my location and staying stable. I was finally able to get it to find my location (I used Google Maps to kick-start the GPS and then it found me - finally). BUT it's lost me again - it keeps dropping connection with the GPS, while on Chrome it's stable.

On my Nexus.
Assignee: nobody → doug.turner
tracking-fennec: ? → 20+
Flags: needinfo?(doug.turner)
Summary: GPS not finding correct location → GPS not finding correct location on Galaxy Nexus
Note: I have not allowed wifi and mobile network location. I am only using GPS satellites. Using my Galaxy Nexus.
Karen, if you enable wifi and mobile network location support, does this problem go away?
Flags: needinfo?(doug.turner)
Ok, so turning on wifi to help find my location works / speeds it up / more stable. So for those who don't want to use wifi, therein lies the stability issue.

(For the record, I was standing by the window for better luck - and to reiterate, Chrome could do it but not Fx).

I'll ask the team who also reported similar issues for their devices & setup and add to the bug as soon as I get that info.
Sounds good.  At least now, with wifi turned on, you have a work around for MWC.
jdm, this is probably a good bugsahoy bug.  care to decorate it as such?
Assignee: doug.turner → nobody
Product: Firefox for Android → Core
Version: Firefox 18 → unspecified
Component: General → Geolocation
Before I do that, could you clarify what the solution is here?
I think we need to compare what chromium does to what firefox android does.  It sounds like Chrome might *somehow* be getting better geo results when wifi is disabled than FF does.
Assignee: nobody → doug.turner
tracking-fennec: 20+ → +
jdm, the solution is to compare exactly what chrome does and to what we do.  Then look at the spec to see if we can improve on our handling of the requires high accuracy hint.
Assignee: doug.turner → nobody
Flags: needinfo?(josh)
I can reproduce this even with Wi-Fi enabled on my Nexus 4.
Assignee: nobody → cpeterson
Return the most recent location, not the most accurate provider's most recent location. When users are indoors, I suspect the GPS provider's most recent location can be older than the network provider's most recent location. We may also want to submit parallel requests to the GPS and network providers because the GPS provider may be slow or blocked.

Also, Gecko calls enableLocation() before enableLocationHighAccuracy(), so we have a potential race condition where enableLocation()'s Runnable reads mLocationHighAccuracy from the UI thread before enableLocationHighAccuracy() sets mLocationHighAccuracy from the Gecko thread. Making mLocationHighAccuracy volatile is a band-aid, not a real fix.
Attachment #746678 - Flags: review?(blassey.bugs)
Flags: needinfo?(josh)
Comment on attachment 746678 [details] [diff] [review]

Review of attachment 746678 [details] [diff] [review]:

::: mobile/android/base/
@@ +394,5 @@
>      }
> +    private static float getLocationAccuracy(Location location) {
> +        float radius = location.getAccuracy();
> +        return (location.hasAccuracy() && radius > 0f) ? radius : 100f;

how did you get a default radius of 100f? I've seen accuracy of 1000m.

@@ +397,5 @@
> +        float radius = location.getAccuracy();
> +        return (location.hasAccuracy() && radius > 0f) ? radius : 100f;
> +    }
> +
> +    private static Location getLastKnownLocation() {

I find it hard to believe android doesn't already provide this functionality
Attachment #746678 - Flags: review?(blassey.bugs) → review+
(In reply to Brad Lassey [:blassey] from comment #13)
> > +        return (location.hasAccuracy() && radius > 0f) ? radius : 100f;
> how did you get a default radius of 100f? I've seen accuracy of 1000m.

I originally used 1000m, but I saw that Android's uses 100m for some locations that don't have an accuracy:

But if you've seen 1000m accuracy from real devices, I can hard code something like 1001m.

> > +    private static Location getLastKnownLocation() {
> I find it hard to believe android doesn't already provide this functionality

AFAICT, Android's LocationManager only supports querying last known location for an individual location provider:
I changed the hard coded 100 to 1001 and removed the float suffix 'f' because dougt thought "100f" looked like "100 feet" instead of meters.
Fixed inbound bustage. Use Location.getTime() instead of getElapsedRealtimeNanos() because getElapsedRealtimeNanos() is only available on Android API Level 17+ and its timestamps are not comparable across device reboots.
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla23
Depends on: 872076
It is fixed in nightly (it has updated my location correctly). Yay!
Verified fixed as per comment 18 :)
You need to log in before you can comment on or make changes to this bug.