Closed Bug 1014924 Opened 6 years ago Closed 6 years ago

[B2G][Tarako][Geolocation] WifiWorker scan fails With wifi off, and geolocation stops

Categories

(Core :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla33
blocking-b2g 1.3T+
Tracking Status
b2g-v1.3T --- fixed
b2g-v2.1 --- fixed

People

(Reporter: garvan, Assigned: vchang)

References

Details

(Whiteboard: geolocation, mozilla location services)

Attachments

(2 files)

Setup: SIM in slot 2, wifi off (cell data on or off, same result)

Get this error in logcat:
W/WifiHW  (   85): wifi_command: SCAN
W/WifiHW  (   85): wifi_command: DRIVER SCAN-ACTIVE
W/WifiHW  (   85): wifi_command: DRIVER SCAN-PASSIVE
W/WifiHW  (   85): wifi_command: SCAN
W/WifiHW  (   85): wifi_command: DRIVER SCAN-PASSIVE
E/GeckoConsole(   85): [JavaScript Error: "this.wantScanResults is undefined" {file: "jar:file:///system/b2g/omni.ja!/components/WifiWorker.js" line: 2503}]
Summary: [B2G][Tarako][Geolocation] WifiWorker scan fails → [B2G][Tarako][Geolocation] WifiWorker scan fails With wifi off, and geolocation stops
blocking-b2g: --- → 1.3T?
NO : naoki to confirm if he can reproduce this and help comment if its a recent regression ? Would be helpful to understand if 1.4/2.0 are affected as well.

Basically help verify if geolocation works on the device when wifi is off(Cell data on and off).
Flags: needinfo?(nhirata.bugzilla)
Keywords: qawanted
(In reply to Garvan Keeley [:garvank] from comment #0)
> Setup: SIM in slot 2, wifi off (cell data on or off, same result)
> 
> Get this error in logcat:
> W/WifiHW  (   85): wifi_command: SCAN
> W/WifiHW  (   85): wifi_command: DRIVER SCAN-ACTIVE
> W/WifiHW  (   85): wifi_command: DRIVER SCAN-PASSIVE
> W/WifiHW  (   85): wifi_command: SCAN
> W/WifiHW  (   85): wifi_command: DRIVER SCAN-PASSIVE
> E/GeckoConsole(   85): [JavaScript Error: "this.wantScanResults is
> undefined" {file: "jar:file:///system/b2g/omni.ja!/components/WifiWorker.js"
> line: 2503}]

Can you help comment the buildid details you are using?
I build with this:
BRANCH=v1.3t ./config.sh tarako
./build.sh gecko && ./flash.sh gecko

My git info is:
## Remote URLs:
origin	https://github.com/mozilla-b2g/B2G.git (fetch)
origin	https://github.com/mozilla-b2g/B2G.git (push)
## Remote Branches:
  origin/HEAD -> origin/master
  origin/master
## Local Branches:
* master
## Most Recent Commit:
commit 7f3e85bd996830ffb0b00ecab80ebf9b9ec2d2ae
Merge: 6b93981 d163526
I was NOT able to reproduce this on today's Tarako Build - Following the STR I did not receive the posted error message in my Logcat.

Environmental Variables:
Device: Tarako 1.3T
BuildID: 20140523081121
Gaia: 44aeb45296737299a988b4d91e3f0c1059caec08
Gecko: 25248a151dfa
Version: 28.1
Firmware Version: sp6821a-gonk-4.0-5-12
Keywords: qawanted
That is good news, same for me. I got my device reflashed with build 20140521183500. Now the bug doesn't occur, but I can't shut off wireless scanning, so I don't see how I can repro it. The wireless stays on, and shows networks.
I think if the code changes to shut off wireless completely when wireless is turned off in the settings, I would think the bug will re-occur.
blocking-b2g: 1.3T? → ---
B2G background wifi scanning is discussed here
https://bugzilla.mozilla.org/show_bug.cgi?id=807148

If there is a change to allow disabling of the wifi scanning (Android 4.4.3 has an option to do this in the Wifi Settings [under Advanced settings]), then the bug will reoccur.
No longer blocks: 1014916
Depends on: 807148, 1014916
Closing as it no longer is reproducible with the wifi scanning always active.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
I can reproduce this bug on the 5/29 nightly on Tarako.

To reproduce I enable my data connection and disable wifi, then launch the Camera app (which requests geolocation) and watch the logcat.

I see a lot of geolocation logging and after about 25 seconds I start to see: 

[JavaScript Error: "this.wantScanResults is undefined" {file: "jar:file:///system/b2g/omni.ja!/components/WifiWorker.js" line: 384}]

in the logcat.  When I exit the camera app, I see the location provider shut down, but these WifiWorker.js error messages continue to appear every few seconds for about 25 seconds.

NetworkLocationProvider.js is querying wifi access points every 5 seconds. I assume that the queries are being queued up and are timing out after about 25s. After they timeout, they're causing this JS error. The error itself is probably benign, but the fact that we are aren't just failing fast when wifi is turned off seems wrong.  

We should presumably fix the bad JS in WifiWorker.js, but maybe NetworkLocationProvider.js could also be modified to not query access points if wifi is disabled?  Or the API for querying those points could fail fast instead when disabled?
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I'm hoping bug 1007953 might help resolve this issue?  I asked in the bug if the fix there would fix the error message.
Flags: needinfo?(nhirata.bugzilla)
Flags: needinfo?(nhirata.bugzilla)
Attached file logcat.txt
To note, I haven't gotten the error message. I have gotten a lot of command rejected error messages.  You can also see the geolocation call in the log.

This is with wifi and mobile data turned off on a tarako with a full flash from today.
bug 1007953 shouldn't have any effect on this bug.
Assignee: nobody → vchang
I think the API for querying those access points should return an error when wifi is disabled. 
Maybe we should modify the API in nsIWifi.idl to 

 0 : success
-1 : wifi is disable or any kind of errors. 
int getWifiScanResults(in nsIWifiScanResultsReady callback);
Attached patch Patch v1.0Splinter Review
Prevent calling the getWifiScanResults API when wifi is turned off.
Attachment #8434039 - Flags: review?(chulee)
Comment on attachment 8434039 [details] [diff] [review]
Patch v1.0

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

Looks good, thanks!
Attachment #8434039 - Flags: review?(chulee) → review+
Blocks: 971637
Not sure if we need this on Tarako per comment 8?
blocking-b2g: --- → 1.3T?
https://hg.mozilla.org/mozilla-central/rev/38e44f89c1c0
Status: REOPENED → RESOLVED
Closed: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla33
Vincent, are there end user impact if we don't take this bug for tarako? thanks
Flags: needinfo?(vchang)
I think user doesn't notice the bug. Just that there might be some error messages in the console.
Flags: needinfo?(vchang)
Flags: needinfo?(nhirata.bugzilla)
Actually, I think the end user impacts is a bit more than just not getting an error.  Doesn't it continue trying process the ping without this patch?  Since there's limited resources on Tarako, it may be beneficial for this patch to be in place if they don't have wifi on.

NI? James, so that he's aware of this patch that has not landed on 1.3T

I think we should take the patch.  It seems low risk to me.  vchang, can you verify please?
Flags: needinfo?(vchang)
Flags: needinfo?(james.zhang)
Zhenqing, please verify it.
I think it's low risk, we can land it.
Flags: needinfo?(james.zhang) → needinfo?(zhenqing.liu)
Verified OK, please land it on v1.3t, thanks.
Verified OK, please land it.
Flags: needinfo?(zhenqing.liu)
ok, I'll prepare the patch for 1.3T. But I don't have the tarako device at home right now. So let me do it on Monday.
Flags: needinfo?(vchang)
I found the patch is also applicable to 1.3t branch. It's not necessary to post the specific patch.
I think Fabrice is back now, can you help to land this patch for v1.3t?
Flags: needinfo?(fabrice)
You need to log in before you can comment on or make changes to this bug.