Closed
Bug 1031567
Opened 10 years ago
Closed 10 years ago
[B2G][Geolocation][Find My Device]Geolocation for FMD is not accurately reporting my correct position
Categories
(Core :: DOM: Geolocation, defect)
Tracking
()
RESOLVED
WORKSFORME
blocking-b2g | 2.0+ |
People
(Reporter: jschmitt, Assigned: gerard-majax)
References
Details
Attachments
(2 files)
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%
Reporter | ||
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Comment 1•10 years ago
|
||
Only available on 2.0 at the moment no need for branch checks.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga)
Comment 2•10 years ago
|
||
Does this reproduce using the HERE maps app?
[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
Flags: needinfo?(hschlichting)
Comment 4•10 years ago
|
||
(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.
Flags: needinfo?(gkeeley)
Updated•10 years ago
|
Flags: needinfo?(hschlichting)
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)
Flags: needinfo?(gkeeley) → needinfo?(jschmitt)
Reporter | ||
Comment 6•10 years ago
|
||
(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
Flags: needinfo?(jschmitt)
Updated•10 years ago
|
Blocks: geo-b2g-2.0
Comment 7•10 years ago
|
||
(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•10 years ago
|
||
(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.
blocking-b2g: backlog → 2.0?
Keywords: qawanted
Comment 9•10 years ago
|
||
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•10 years ago
|
||
(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.
Updated•10 years ago
|
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage+][lead-review+]
Comment 12•10 years ago
|
||
(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•10 years ago
|
||
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.
Flags: needinfo?(dougt)
Summary: [B2G][Geolocation][Find My Device]Geolocation for FMD is not accuretly reporting my correct position → [B2G][Geolocation][Find My Device]Geolocation for FMD is not accurately reporting my correct position
Comment 15•10 years ago
|
||
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
Flags: needinfo?(jschmitt)
Comment 16•10 years ago
|
||
Garvan, if you need to know anything about Flame in details, Francis Lee(frlee@mozilla.com) 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•10 years ago
|
||
I see that Josh already answered he is using PVT builds.
Flags: needinfo?(jschmitt)
Comment 18•10 years ago
|
||
Isn't 2.0 the QC geo stack?
Marking my Comment 14 as spam, I am using 2.1 on Flame.
Comment 19•10 years ago
|
||
(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.
Flags: needinfo?(frlee)
Comment 20•10 years ago
|
||
Assigning to Garvan for now because the B2G release driver want all 2.0+ blockers to have an assignee. <:)
Assignee: nobody → gkeeley
status-b2g-v2.1:
--- → ?
Comment 21•10 years ago
|
||
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
Flags: needinfo?(frlee)
Comment 22•10 years ago
|
||
(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?
Flags: needinfo?(vyang)
Comment 23•10 years ago
|
||
(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.
Flags: needinfo?(vyang)
Comment 24•10 years ago
|
||
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.
Flags: needinfo?(cpeterson)
Comment 25•10 years ago
|
||
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.
Assignee: gkeeley → nobody
Flags: needinfo?(cpeterson)
Comment 26•10 years ago
|
||
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.
Keywords: qawanted
Comment 29•10 years ago
|
||
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•10 years ago
|
||
s/2.0+MLS/2.0 + Mozilla Geo Stack/
in comment 29
Assignee | ||
Comment 31•10 years ago
|
||
I'm wondering if it could indeed be https://github.com/mozilla/ichnaea/issues/280 ?
Flags: needinfo?(jschmitt)
Assignee | ||
Comment 32•10 years ago
|
||
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•10 years ago
|
||
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.
Flags: needinfo?(hschlichting)
Comment 34•10 years ago
|
||
(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.
Flags: needinfo?(hschlichting)
Assignee | ||
Comment 36•10 years ago
|
||
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?
Flags: needinfo?(jschmitt)
Comment 38•10 years ago
|
||
(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.
Reporter | ||
Comment 39•10 years ago
|
||
(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
Flags: needinfo?(jschmitt)
Comment 40•10 years ago
|
||
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?
Assignee | ||
Comment 41•10 years ago
|
||
(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.
Flags: needinfo?(jschmitt)
Assignee | ||
Comment 42•10 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 43•10 years ago
|
||
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.
Flags: needinfo?(jschmitt)
You need to log in
before you can comment on or make changes to this bug.
Description
•