1031567 - [B2G][Geolocation][Find My Device]Geolocation for FMD is not accurately reporting my correct position

Status: RESOLVED WORKSFORME

(Core :: DOM: Geolocation, defect)

Description

[Josh Schmitt [Joshs]]

Attachment: log.txt

Description:
Geolocation on https://fmd.stage.mozaws.net for Find My Deivce is not accurately showing my correct position of my phone

Repro Steps:
1) Update a Flame to 20140627000201
2) Turn Cell Data on 
3) Follow steps to install at https://wiki.mozilla.org/User_Services/Try_FMD
4) Open Settings > Firefox Accounts
5) Sign up for an account and confirm the account
6) Open Settings > Find My Device
7) Turn on Find My Device
8) On a pc load https://fmd.stage.mozaws.net and sign in

Actual:
Website shows that I am in California e.g. 1200 miles away. I'm using a SIM from California

Expected:
The website shows my exact location or reletively close to my location (Washington).

Environmental Variables:
Device: Flame 2.0
Build ID: 20140627000201
Gaia: 8df02268fcd7e80c5fab8c1ec099772e37f8659d
Gecko: 731a5e8831e6
Version: 32.0a2 (2.0)
Firmware Version: v122

User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Notes:
Repro frequency: 40%

Comment 1

[Peter Bylenga [:PBylenga]]

Only available on 2.0 at the moment no need for branch checks.

Comment 2

[Jason Smith [:jsmith]]

Does this reproduce using the HERE maps app?

Comment 3

[:garvan]

[Note for Hanno, marking you as "need info": I don't need info, just clear the flag when you have read. I wanted you to see this weird RIL behaviour and be aware it can report old cell tower locations (you probably already are aware of this anyway).]

The important log bits are here. Initially the RIL reports a cell that MLS service says is in Los Angeles.
Then, a wifi scan happens, another request is sent to MLS, and it reports back a location in Kirkland WA: 47.7080264,-122.2102988. Note MLS uses the wifi scan to override the stale cell tower info, as the Los Angeles cell tower is still being reported by the RIL.

*** WIFI GEO: Sending request: https://location.services.mozilla.com/v1/geolocate?key=no-mozilla-api-key
*** WIFI GEO: sending {"cellTowers":[{"radio":"gsm","mobileCountryCode":"310","mobileNetworkCode":"410","locationAreaCode":42980,"cellId":9387291}]}
*** WIFI GEO: gls returned status: 200 --> {"location":{"lat":34.0522,"lng":-118.2437},"accuracy":50000}
*** WIFI GEO: Sending request: https://location.services.mozilla.com/v1/geolocate?key=no-mozilla-api-key
*** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"08-60-6e-22-ae-80","signalStrength":-47},{"macAddress":"28-c6-8e-0c-ab-e7","signalStrength":-53},{"macAddress":"98-fc-11-81-df-c6","signalStrength":-55},{"macAddress":"00-24-7b-91-96-26","signalStrength":-55},{"macAddress":"98-fc-11-81-df-c8","signalStrength":-58},{"macAddress":"44-94-fc-03-13-d1","signalStrength":-62},{"macAddress":"60-a4-4c-8d-0d-b8","signalStrength":-69},{"macAddress":"00-24-7b-91-7b-fb","signalStrength":-71},{"macAddress":"00-25-9c-5f-c6-73","signalStrength":-74},{"macAddress":"00-25-9c-9a-50-2c","signalStrength":-78},{"macAddress":"00-26-5a-b5-b4-b3","signalStrength":-80},{"macAddress":"c0-c1-c0-9f-59-a0","signalStrength":-87}],"cellTowers":[{"radio":"gsm","mobileCountryCode":"310","mobileNetworkCode":"410","locationAreaCode":42980,"cellId":9387291}]}
*** WIFI GEO: gls returned status: 200 --> {"location":{"lat":47.7080264,"lng":-122.2102988},"accuracy":100}
*** WIFI GEO: shutdown called

Comment 4

[Hanno Schlichting]

(In reply to Garvan Keeley [:garvank] from comment #3)
> The important log bits are here. Initially the RIL reports a cell that MLS
> service says is in Los Angeles.

Not quite. It says you are in Los Angeles based on a GeoIP result.

This particular code is still missing the UMTS support patch, and sends the wrong "radio": "gsm". With a correct "radio": "wcdma", the result would be lat: 47.7232, lon: -122.3389, accuracy: 20000. While MLS doesn't have an entry for the exact cell id, it has an entry for the location area of this cell.

> Then, a wifi scan happens, another request is sent to MLS, and it reports
> back a location in Kirkland WA: 47.7080264,-122.2102988. Note MLS uses the
> wifi scan to override the stale cell tower info, as the Los Angeles cell
> tower is still being reported by the RIL.
> 
> *** WIFI GEO: Sending request:
> https://location.services.mozilla.com/v1/geolocate?key=no-mozilla-api-key

What kind of build was this? I'm wondering where the no-mozilla-api-key is coming from.

Comment 5

[:garvan]

Josh, where did you build this yourself, or is coming of a release eng build machine. It doesn't look like the MLS API key is set correctly (although we do accept that key currently)

Comment 6

[Josh Schmitt [Joshs]]

(In reply to Garvan Keeley [:garvank] from comment #5)
> Josh, where did you build this yourself, or is coming of a release eng build
> machine. It doesn't look like the MLS API key is set correctly (although we
> do accept that key currently)

I use the nightly builds on PVT

https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-flame/2014/06/2014-06-27-00-02-01/

I also follow these instructions to set up FMD on my device

https://wiki.mozilla.org/User_Services/Try_FMD

Comment 7

[Marcia Knous [:marcia]]

(In reply to Jason Smith [:jsmith] from comment #2)
> Does this reproduce using the HERE maps app?

Over the weekend I tried Here Maps, and it located me precisely. But when I tried the FMD geolocation it didn't work (spinning icon). In my case I performed an OTA with my device when I last tested this.

Comment 8

[Jason Smith [:jsmith]]

(In reply to Marcia Knous [:marcia - use needinfo] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #2)
> > Does this reproduce using the HERE maps app?
> 
> Over the weekend I tried Here Maps, and it located me precisely. But when I
> tried the FMD geolocation it didn't work (spinning icon). In my case I
> performed an OTA with my device when I last tested this.

Okay - this might be specifically showing up on the FMD site due to how it interacts with the geolocation API. The fact that we're in a wrong state though is a clear blocker.

Comment 9

[Erin Lancaster [:elan]]

See, dougt's comment: https://bugzilla.mozilla.org/show_bug.cgi?id=1030216#c4. We should also probably dupe one of these bugs.

Comment 10

[Jason Smith [:jsmith]]

(In reply to Erin Lancaster [:elan] from comment #9)
> See, dougt's comment:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1030216#c4. We should also
> probably dupe one of these bugs.

I'm not sure this is a dupe. That bug points to a 1 mile difference in location, where as this bug points to being in the wrong state due to the difference of what the RIL reports vs. what wifi reports.

Comment 11

[Kai-Chih Hu [:khu]]

So, should we find an owner for this bug? Thanks!

Comment 12

[Kai-Chih Hu [:khu]]

(In reply to Jason Smith [:jsmith] - PTO 7/14 - 7/18 from comment #8)
> (In reply to Marcia Knous [:marcia - use needinfo] from comment #7)
> > (In reply to Jason Smith [:jsmith] from comment #2)
> > > Does this reproduce using the HERE maps app?
> > 
> > Over the weekend I tried Here Maps, and it located me precisely. But when I
> > tried the FMD geolocation it didn't work (spinning icon). In my case I
> > performed an OTA with my device when I last tested this.
> 
> Okay - this might be specifically showing up on the FMD site due to how it
> interacts with the geolocation API. The fact that we're in a wrong state
> though is a clear blocker.

Does it mean that this should be NPOTB?

Comment 13

[Chris Peterson [:cpeterson]]

Garvan, can you investigate this 2.0 blocker? From Hanno's comment 4, this sounds like MLS is falling back to GeoIP (which might be a "fact of life", not a bug we can fix), but Marcia's comment 7 sounds like HERE Maps works but not FMD.

Comment 15

[:garvan]

Are you installing the PVT builds? My assumption is that you are using non-QC builds, and that the PVT builds have the Mozilla geolocation stack.

I am new to Flame, I need to learn which builds have which geolocation stack. My understanding was that official Flame builds would have the QC geo stack.

As for setting my phone up with the Mozilla geo stack for me to debug and fix, I am blocked by this build error ATM:
https://bugzilla.mozilla.org/show_bug.cgi?id=1024846

Comment 16

[Kai-Chih Hu [:khu]]

Garvan, if you need to know anything about Flame in details, Francis Lee([e-mail]) would be a good point of contact for you. Please let us know what we can help to speed up the process. This is a 2.0+ blocker, and we're targeting to fix it by this week. Thank you.

Comment 17

[:garvan]

I see that Josh already answered he is using PVT builds.

Comment 18

[:garvan]

Isn't 2.0 the QC geo stack? 

Marking my Comment 14 as spam, I am using 2.1 on Flame.

Comment 19

[Kai-Chih Hu [:khu]]

(In reply to Garvan Keeley [:garvank] from comment #18)
> Isn't 2.0 the QC geo stack? 
> 
> Marking my Comment 14 as spam, I am using 2.1 on Flame.

My understanding is yes, but Francis could have much accurate answer for this. Ni Francis here.

Comment 20

[Chris Peterson [:cpeterson]]

Assigning to Garvan for now because the B2G release driver want all 2.0+ blockers to have an assignee. <:)

Comment 21

[Francis Lee [:frlee]]

hi All,

once you replace gaia/gecko, QC RIL is replaced by Moz RIL.
about Flame's GPS, please refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1036319#c2
MOZ RIL doesn't support "GPS only", it needs wifi/3G to make Geolocation accurate

Flame's v1.3 base image (v122) works normally per Taipei QA's comment.

you can also refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1023647
test is correct, but result is wrong, and it's not due to Flame specific

Comment 22

[Mike Lien[:mlien]]

(In reply to Francis Lee [:frlee] from comment #21)
> hi All,
> 
> once you replace gaia/gecko, QC RIL is replaced by Moz RIL.
> about Flame's GPS, please refer to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1036319#c2
> MOZ RIL doesn't support "GPS only", it needs wifi/3G to make Geolocation
> accurate
> 
> Flame's v1.3 base image (v122) works normally per Taipei QA's comment.
> 
> you can also refer to https://bugzilla.mozilla.org/show_bug.cgi?id=1023647
> test is correct, but result is wrong, and it's not due to Flame specific

Let me clarify one thing, I give the incorrect bug to Francis for reference
Above bug is Tarako issue and it's due to 2.5G GSM/EDGE which Hanno had explained before

In Flame, v1.3 with QC RIL can get exact location
If update to v1.4/v2.0/v2.1, it's Moz RIL
But I'm not sure if Moz RIL contains QC geo stack

ni vicamo for more information
hi vicamo, do you happen to know if Moz RIL contains QC geo stack?

Comment 23

[Vicamo Yang [:vicamo][:vyang]]

(In reply to Mike Lien[:mlien] from comment #22)
> Let me clarify one thing, I give the incorrect bug to Francis for reference
> Above bug is Tarako issue and it's due to 2.5G GSM/EDGE which Hanno had
> explained before
> 
> In Flame, v1.3 with QC RIL can get exact location
> If update to v1.4/v2.0/v2.1, it's Moz RIL
> But I'm not sure if Moz RIL contains QC geo stack
> ni vicamo for more information
> hi vicamo, do you happen to know if Moz RIL contains QC geo stack?

Of course not! No one is allowed to distribute proprietary properties without approval. If you do, please stop. Besides, please note we don't install MozRIL on Flame or any other QC based platforms.

Comment 24

[:garvan]

My understanding:
Is that geolocation bugs of the combination Flame + b2g 2.0 (and Mozilla Geo Stack), must be repro'd on the QC official build. 
If not repro'd on QC official build, bug goes to 2.1 to fix.

Regardless, I'll investigate this in the MLS side.

Comment 25

[:garvan]

cpeterson and I discussed. 

This bug needs to be verified by QA on TCL (QC-stack) builds. If it happens there, it gets assigned to QC.

Comment 26

[Jason Smith [:jsmith]]

I'm going to clarify this offline with Erin, but comment 25 isn't a feasible request. TCL builds are only provided for a particular version after the relevant chipset has been CS certified. That means we cannot place a dependency on having those builds being available while release testing is underway at Mozilla.

Comment 29

[:garvan]

2.0+MLS is now a reality, which changes things. 

Bugs such as 
https://bugzilla.mozilla.org/show_bug.cgi?id=878748

Were not ported because of the previous understanding that only the QC geo layer was going into 2.0 as an official product. That bug, for example is critical for AGPS if your SIM isn't in the first slot (or only works in the 2nd).

I am PTO, ATM, will check with cpeterson to see if I can help to track down missing patches. But we need more eyes on this to ensure all the geo patches get to 2.0

Comment 30

[:garvan]

s/2.0+MLS/2.0 + Mozilla Geo Stack/
in comment 29

Comment 31

[:gerard-majax]

I'm wondering if it could indeed be https://github.com/mozilla/ichnaea/issues/280 ?

Comment 32

[:gerard-majax]

Josh, I also had Geolocation issues that were due to MLS not behaving properly with different SIM cards/radio technologies.

I'm doubtful we should block 2.0 on this, most of those issues are not related to Gecko or Gaia.

Comment 33

[Chris Peterson [:cpeterson]]

Hanno: can we prioritize Ichnaea issue #280 ("trust cell position over GeoIP position") for B2G 2.0? I think Garvan added client-side code to prefer accurate results over recent results, but that depends on MLS sending accurate results to the client.

Comment 34

[Hanno Schlichting]

(In reply to Chris Peterson (:cpeterson) from comment #33)
> Hanno: can we prioritize Ichnaea issue #280 ("trust cell position over GeoIP
> position") for B2G 2.0? I think Garvan added client-side code to prefer
> accurate results over recent results, but that depends on MLS sending
> accurate results to the client.

I'm working on #280 as we speak. Though our statistics say that it is a rare edge-case, where the GeoIP result is wrong and we actually have data for the cell in question.

Comment 35

[Josh Schmitt [Joshs]]

I agree.

Comment 36

[:gerard-majax]

Josh, I have been using FMD and geolocation quite a lot recently and I could not identify new bad behavior like this one.

Do you mind rechecking and/closing if needed?

Comment 37

[:gerard-majax]

Taking to track.

Comment 38

[Hanno Schlichting]

(In reply to Hanno Schlichting [:hannosch] from comment #34)
> (In reply to Chris Peterson (:cpeterson) from comment #33)
> > Hanno: can we prioritize Ichnaea issue #280 ("trust cell position over GeoIP
> > position") for B2G 2.0? I think Garvan added client-side code to prefer
> > accurate results over recent results, but that depends on MLS sending
> > accurate results to the client.
> 
> I'm working on #280 as we speak. Though our statistics say that it is a rare
> edge-case, where the GeoIP result is wrong and we actually have data for the
> cell in question.

Ichnaea issue #280 was fixed and the fix deployed today.

Comment 39

[Josh Schmitt [Joshs]]

(In reply to Alexandre LISSY :gerard-majax from comment #36)
> Josh, I have been using FMD and geolocation quite a lot recently and I could
> not identify new bad behavior like this one.
> 
> Do you mind rechecking and/closing if needed?

I was signed into FMD and looking at the website, then my location proceeded to jump a few times (about an estimated 15+ miles) if I alt tabbed out of the window, maybe a new bug should be filed regarding that?. Not sure if that is expected behavior regarding FMD

Comment 40

[Chris Peterson [:cpeterson]]

Since the position jumping is on the FMD website, I wonder if the problem is the client reporting inaccurate positions to the FMD server or the FMD server sending more recent, but less accurate positions to the FMD website?

Comment 41

[:gerard-majax]

(In reply to Josh Schmitt [Joshs] from comment #39)
> (In reply to Alexandre LISSY :gerard-majax from comment #36)
> > Josh, I have been using FMD and geolocation quite a lot recently and I could
> > not identify new bad behavior like this one.
> > 
> > Do you mind rechecking and/closing if needed?
> 
> I was signed into FMD and looking at the website, then my location proceeded
> to jump a few times (about an estimated 15+ miles) if I alt tabbed out of
> the window, maybe a new bug should be filed regarding that?. Not sure if
> that is expected behavior regarding FMD

How does this related specifically to FMD ?
Can you assert that FMD was reporting a wrong position when the device could get a good one ?
Can it be due to a MLS issue ?

Please check it properly, enable geolocation debug in Settings, Developper, and cross check.

This is marking blocking 2.0 but there is nothing usable for now.

Comment 42

[:gerard-majax]

Okay, we have no news on this bug and my dogfooding does not expose it anymore either. Let's close this. If you still experience this, feel free to reopen.

Comment 43

[Josh Schmitt [Joshs]]

Attachment: log.txt

In reply to Comment 41 and 42.

When first loading FMD via desktop web browser my location was about 15mi from where I actually am for a couple seconds (around 10 seconds) then was updated and consistently worked, I have included a logcat of my experience.