805965 - Geolocation fix "jerks around"

Status: RESOLVED FIXED

(Core :: DOM: Device Interfaces, defect, P2)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

STR
 (1) Open Maps app
 (2) Initially, we get a coarse fix.  IP or wifi positioning?
 (3) Wait for a precise GPS fix

After the GPS fix, I see the current location in Maps "jerk" back and forth between the coarse fix in (2) and the precise fix in (3).

I would expect that once a high-precision locator becomes available, we use it exclusively and ignore or disable low-precision sources.

Comment 1

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Suggest blocking-basecamp for major usability issue.  This makes geolcation in the Maps app pretty much useless.

Comment 2

[Doug Turner (:dougt)]

The wifi/ip position and the gps position are both being sent to the document. We use to have code to filter/blend locations.

I agree that it should be fixed for basecamp.  Assigning.  I can look at it shortly.

Comment 3

[Doug Turner (:dougt)]

Attachment: patch v.1

It would be really cool if someone could try this patch out

Comment 4

[Kan-Ru Chen [:kanru] (UTC+9)]

Works great!

Comment 5

[Doug Turner (:dougt)]

Comment on attachment 677171 [details] [diff] [review]
patch v.1

Review of attachment 677171 [details] [diff] [review]:
-----------------------------------------------------------------

jdm, do you think you can take a look?

Comment 6

[Josh Matthews [:jdm]]

Comment on attachment 677171 [details] [diff] [review]
patch v.1

Review of attachment 677171 [details] [diff] [review]:
-----------------------------------------------------------------

I'd like somebody else to sign off on the math; it went over my head :/

::: dom/src/geolocation/nsGeolocation.cpp
@@ +709,5 @@
>    }
>    return NS_OK;
>  }
>  
> +PRBool

Plain old bool, please, and associate return value changes.

@@ +716,5 @@
> +  if (!aSomewhere) {
> +    return false;
> +  }
> +  
> +  if (mProviders.Count() == 1 || mLastPosition == nullptr) {

!mLastPosition

@@ +722,5 @@
> +  }
> +
> +  nsresult rv;
> +  DOMTimeStamp oldTime;
> +  rv = mLastPosition->GetTimestamp(&oldTime);

Do you intend to do anything with oldTime?

@@ +744,5 @@
> +  NS_ENSURE_SUCCESS(rv, PR_FALSE);
> +
> +
> +  DOMTimeStamp newTime;
> +  rv = aSomewhere->GetTimestamp(&newTime);

Were you going to be using this, too?

@@ +779,5 @@
> +                       (cos(rNewLat) * cos(rOldLat) * cos(rOldLon - rNewLon)) ) * 6378137; 
> +
> +  // The threshold is when the distance between the two positions exceeds the
> +  // worse (larger value) of the two accuracies.
> +  double max_accuracy = PR_MAX(oldAccuracy, newAccuracy);

NS_MAX

Comment 7

[Doug Turner (:dougt)]

Attachment: patch v.2

Kan-Ru, would you mind also testing this patch? This is much more straight forward and probably works just fine.

Comment 8

[Kan-Ru Chen [:kanru] (UTC+9)]

Will the old "better" position expire? If I get a accurate fix via gps then go into a building, all later updates from IP positioning will be discarded and I will not get any update.

Also the large movement case could happen in real life. Imagine that I get a accurate fix, then I take the subway, on the subway I have wifi so I could get a coarse location.

Comment 9

[Doug Turner (:dougt)]

Comment on attachment 677666 [details] [diff] [review]
patch v.2

That's fair.

we should use patch v.1.  bz said he wanted comments about the math used.  We should also look at the time and expire as Kan-Ru suggests.

Comment 10

[Doug Turner (:dougt)]

Attachment: patch v.2

Comment 11

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 678799 [details] [diff] [review]
patch v.2

This looks good.

It might still make sense to mention that this comes out of applying the spherical law of cosines to the triangle formed by our two points and the north pole.

Comment 12

[Josh Matthews [:jdm]]

Please address comment 6 before landing.

Comment 13

[Doug Turner (:dougt)]

https://hg.mozilla.org/mozilla-central/rev/30b340a71112
https://hg.mozilla.org/releases/mozilla-aurora/rev/db23dcb2f68d

Comment 14

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to Josh Matthews [:jdm] from comment #6)
> Comment on attachment 677171 [details] [diff] [review]
> patch v.1
> 
> Review of attachment 677171 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I'd like somebody else to sign off on the math; it went over my head :/
> 
> ::: dom/src/geolocation/nsGeolocation.cpp
> @@ +709,5 @@
> >    }
> >    return NS_OK;
> >  }
> >  
> > +PRBool
> 
> Plain old bool, please, and associate return value changes.

Silly you, you still missed this :)

Comment 15

[Doug Turner (:dougt)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/d84a2be98735
https://hg.mozilla.org/mozilla-central/rev/ed13d73c61bb

backed out for bug 690913.

Comment 16

[Andrew Halberstadt [:ahal]]

We recently disabled test_geolocation.js due to intermittent failure (we're enabling webAPI tests sometime tomorrow or Thursday on tbpl): https://hg.mozilla.org/integration/mozilla-inbound/rev/a22328aa1130#l2.9

Could this be the cause?

Comment 17

[Doug Turner (:dougt)]

I don't think so..  It's a real bug (yeah!!! for regression tests)

I am trying out this:
  https://tbpl.mozilla.org/?tree=Try&rev=7208a31a6f90

Comment 18

[Josh Matthews [:jdm]]

The patch at https://hg.mozilla.org/try/rev/c367403ef2c0 should probably update mIsFirstUpdate.

Comment 19

[Doug Turner (:dougt)]

Attachment: patch v.3

a bit more involved.

Comment 20

[Josh Matthews [:jdm]]

Comment on attachment 679469 [details] [diff] [review]
patch v.3

Review of attachment 679469 [details] [diff] [review]:
-----------------------------------------------------------------

The delta check ensures that even if a user is on the move and keeps receiving positions with strictly worse accuracy than the cached value, a long-running app using watchPosition will eventually receive an update, right? r=me if that's the case.

::: dom/src/geolocation/nsGeolocation.cpp
@@ +518,5 @@
> +  // in the case when newly detected positions are all less accurate than the cached one.
> +  //
> +  // Fixes bug 596481
> +  if (mIsFirstUpdate || aIsBetter) {
> +    mIsFirstUpdate = PR_FALSE;

One day we'll fix this nervous PR tic of yours.

Comment 21

[Mozilla RelEng Bot]

Try run for c565b9be1ddf is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=c565b9be1ddf
Results (out of 17 total builds):
    failure: 17
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-c565b9be1ddf

Comment 22

[Mozilla RelEng Bot]

Try run for c565b9be1ddf is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=c565b9be1ddf
Results (out of 18 total builds):
    failure: 18
Builds (or logs if builds failed) available at:
http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-c565b9be1ddf

Comment 23

[Doug Turner (:dougt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/c98b2e425857

Comment 24

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/c98b2e425857

Comment 25

[Doug Turner (:dougt)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/38bff1f270d0

Comment 26

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

(In reply to :Ms2ger from comment #14)
> (In reply to Josh Matthews [:jdm] from comment #6)
> > Comment on attachment 677171 [details] [diff] [review]
> > patch v.1
> > 
> > Review of attachment 677171 [details] [diff] [review]:
> > -----------------------------------------------------------------
> > 
> > I'd like somebody else to sign off on the math; it went over my head :/
> > 
> > ::: dom/src/geolocation/nsGeolocation.cpp
> > @@ +709,5 @@
> > >    }
> > >    return NS_OK;
> > >  }
> > >  
> > > +PRBool
> > 
> > Plain old bool, please, and associate return value changes.
> 
> Silly you, you still missed this :)

And managed to miss it again!