Created an attachment (id=1172917) Part 1 video of the reference vs the DUT DEFECT DESCRIPTION: Geolocation is really slow when you use a app like maps. Takes too long to pin point your exact location REPRODUCING PROCEDURES: In the search tab in the man page look for "maps" choose google maps or any other option, open it, click on the button for location. EXPECTED BEHAVIOUR: To be quick, i know is AGPS but it should find you in less than a minute

Hi my results where that in the Fire 2 3.5, aprox time was 10 minutes for exact location in the Fire C it was 2 and a half minutes, big difference, same wifi network, both just had a factory reset.

Hi Jamin, Could you help to check this issue? Thanks!

Hi sync-1@bugzilla.tld, I have few questions for you. Did this test was conducted in indoor environment without SIM card ? Where did the test was conducted ? Would you please provide the name of city or the latitude and longitude ? I can't reproduce this bug on Fire 2(3.5) in Taipei. (It took about 3 seconds to get MLS location.) Device version: - Firefox OS: 2.0m - Build Identifier：20150303154026 - git commit info : a1b59597 Would you mind to provide "Gecko Geolocation Log" by turn it on in Settings app ? Here is the procedure to produce "Gecko Geolocation Log". 1) Turn on Developer Menu [Settings] --> [Device information] ---> [More Information] --> [Developer Menu] 2) Turn on ADB debugging [Settings] --> [Debugging via USB] ---> [ADB an DevTools] 3) Turn on Geolocation log [Settings] --> [Developer] ---> [Geolocation output in ADB] 4) Turn on WiFI 5) Open Browser app and open any remote page to make sure WiFi connection is functional. 6) Use the ADB command "adb logcat -v time" to save the log and time 7) Use geoloc app, google map or HERE map to query the location. Thank you very much. :)

Created an attachment (id=1187071) LOG from Moxico

Created an attachment (id=1187071) LOG from Moxico

Created an attachment (id=1187071) LOG from Moxico

Revise name to reflect actual issue is MLS.

(In reply to sync-1 from comment #9) > Created attachment 8575101 [details] > LOG from Moxico > > Created an attachment (id=1187071) > LOG from Moxico Hi Reporter, Which device log is this? Fire C or Woodduck?

(In reply to comment #6) > Comment from Mozilla:(In reply to sync-1 from comment #9) > > Created attachment 8575101 [details] > > LOG from Moxico > > > > Created an attachment (id=1187071) [details] > > LOG from Moxico > Hi Reporter, > Which device log is this? Fire C or Woodduck? Woodduck device

Created an attachment (id=1188869) geo log of fire 235 and fire E in huizhi

Created an attachment (id=1188869) geo log of fire 235 and fire E in huizhi

Created an attachment (id=1188869) geo log of fire 235 and fire E in huizhi

Hi Jamin, Could you help to check the log from China team per comment 15? Thanks!

Hi Henry, NetworkGeolocationProvider uses WifiMonitor to scan available WiFi APs and send list of APs to MLS server for positioning. https://dxr.mozilla.org/mozilla-central/source/dom/system/NetworkGeolocationProvider.js#311 In Taipei office, Fire 2 (3.5) can find a lot of APs during MLS positioning in Taipei. > *** WIFI GEO: sending {"wifiAccessPoints":[ > {"macAddress":"00-00-00-00-00-00","signalStrength":0}, > {"macAddress":"dc-38-e1-83-13-44","signalStrength":-37}, > {"macAddress":"dc-38-e1-83-13-48","signalStrength":-37}, > {"macAddress":"dc-38-e1-83-13-46","signalStrength":-37} ... MLS works well on Fire 2 (3.5) in Taipei, however, our partner reported that MLS can't work well in Moxico. I noticed the log in #attachment 8572465 [details] indicates that Fire 2(3.5) didn't find any APs by WiFi scanning. > *** WIFI GEO: sending {} However, there are few WiFi AP was logged in log file. > D/WifiHW ( 167): leave --> reply=bssid / frequency / signal level / flags / ssid > D/WifiHW ( 166): 24:0a:11:7b:c6:02 2422 -67 [WPA2-PSK-CCMP][WPS][ESS] H850-VAL > D/WifiHW ( 166): 1c:e6:c7:f0:57:71 2437 -60 [WPA2-PSK-CCMP+TKIP][ESS] TCTPortal > D/WifiHW ( 166): 1c:e6:c7:f0:57:70 2437 -60 [WPA2-PSK-CCMP+TKIP][ESS] TCTMobile > D/WifiHW ( 166): 1c:e6:c7:f0:57:74 2437 -60 [WPA2-EAP-CCMP][ESS] EAP-SIM > ... > D/WifiHW ( 167): enter -->wifi_send_command cmd=IFNAME=wlan0 DRIVER SCAN-PASSIVE Do you have any idea why these WiFi APs can't be found by WifiMonitor ? Thank you.

Created an attachment (id=1189910) mozilla build geo log and screen shot in huizhou

Created an attachment (id=1189910) mozilla build geo log and screen shot in huizhou

Created an attachment (id=1189910) mozilla build geo log and screen shot in huizhou

Hi Jamin, Could you please help to check the log for Woodduck of Mozilla build per comment 20? Thanks!

I compared the log from #attachment 8575798 [details] with the log from #attachment 8575872 [details]. Although TCL build didn't find any WiFi APs by WiFi scaning, Mozilla build found many WiFi Aps during MLS positioning. Fire 2 (3.5) with TCL build (FxOS 2.0m) > *** WIFI GEO: sending {} Fire 2 (3.5) with mozilla build (FxOS 2.0m) > *** WIFI GEO: sending {"wifiAccessPoints":[{"macAddress":"00-00-00-00-00-00","signalStrength":0},{"macAddress":"3a-a4-f6-71-ac-8b","signalStrength":-56},{"macAddress":"54-78-1a-a1-fc-60","signalStrength":-57},{"macAddress":"4e-a4-89-1a-f3-4d","signalStrength":-58},{"macAddress":"54-78-1a-a1-27-10","signalStrength":-58},{"macAddress":"a2-dc-ea-b9-a6-d0","signalStrength":-58},{"macAddress":"62-a4-81-2c-c3-a1","signalStrength":-59},{"macAddress":"02-11-22-33-44-40","signalStrength":-60},{"macAddress":"a2-ab-af-9d-f8-d0","signalStrength":-60},{"macAddress":"02-5b-42-35-28-1b","signalStrength":-61},... Both MLS results are inaccurate, however, the causes are different. TCL build build can't get accurate location from MLS since the WiFi scan isn't functional. Mozilla build can't get accurate location from MLS since there is no MLS collected data samples in Huizhi. (Please refer to https://location.services.mozilla.com/map#2/15.0/10.0) I think we should test Mozilla build 2.0m in Mexico to clarify the issue.

It appears there're access points in the testing environment but none of them were seen for location query request. If this issue can be reproduced with 2.0m, we can then focus on the location provider components.

what we should do is find out the cause why requestData is null of code "xhr.send(requestData);" with TCL build Fire 2 (3.5) with TCL build (FxOS 2.0m) > *** WIFI GEO: sending {} onChange: function(accessPoints) in file NetworkGeolocationProvider.js, where the value "accessPoints" passed from?

Hi Henry, Could you please shade some light on the question per comment 24? Thank you!

(In reply to sync-1 from comment #24) > what we should do is find out the cause why requestData is null of code > "xhr.send(requestData);" with TCL build > > Fire 2 (3.5) with TCL build (FxOS 2.0m) > > *** WIFI GEO: sending {} > > > onChange: function(accessPoints) in file NetworkGeolocationProvider.js, > where the value "accessPoints" passed from? |onChange| is callback function by |wifiService.startWatching|. You can also refer to nsIWifiListener.idl for further information!

Created an attachment (id=1194121) geo log after fix AP scan issue in México please refer to the geo log Access Point info was sent to MLS this time. the test location is City "Guadalajara – Jalisco – México" Here is test result descrition ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Created an attachment (id=1194121) geo log after fix AP scan issue in México please refer to the geo log Access Point info was sent to MLS this time. the test location is City "Guadalajara – Jalisco – México" Here is test result descrition ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Created an attachment (id=1194121) geo log after fix AP scan issue in México please refer to the geo log Access Point info was sent to MLS this time. the test location is City "Guadalajara – Jalisco – México" Here is test result descrition ” aproximatelocation was faster and more accurate than before, the problem is that this time is that the exact location is never given”

Hi mozilla friends, This is a urgent issue, please help to handle ASAP, thanks !

(In reply to sync-1 from comment #30) > Hi mozilla friends, > > This is a urgent issue, please help to handle ASAP, thanks ! Hi sync-1@bugzilla.tld, MLS can only provide approximate location. If users want to get precise location, they have to use GPS. According to the log, The MLS result is (20.6449596, -103.4070207). http://maps.google.com/maps?q=20.6449596%2c-103.4070207 Could you provide the actual latitude and longitude as a ground truth ?

Update: Qualcomm replaces LocationProvider from Mozilla at vendor/qcom/proprietary/b2g_location. The server is not the same as Mozilla Location Server. The result is as expected now.

(In reply to Josh Cheng [:josh] from comment #32) > Update: > Qualcomm replaces LocationProvider from Mozilla at > vendor/qcom/proprietary/b2g_location. The server is not the same as Mozilla > Location Server. The result is as expected now. Could you please confirm that Woodduck (not QC based product) is not having this issue anymore? I only want to be sure we are on the same page.

Hi Beatriz: Regards to MLS "slow" symptom addressed in this bug title, I think it was clarified as a bug during OEM integration, and get fixed already. Thus we put WORKSFORME here. The left MLS related symptom we see, is the precision of MLS in some discussion and we think this is limited by it's design and the ricnness of database of the area under test. Please let us know if any further question, thank you!

Hi wei, CTS has closed the bug, I think it is time ti close. thanks for mozilla firends.