Closed Bug 1032015 Opened 5 years ago Closed 5 years ago

nsWifiMonitorGonk takes 5 sec to start scanning, and geolocation must wait


(Firefox OS Graveyard :: Wifi, defect)

Gonk (Firefox OS)
Not set


(blocking-b2g:1.4+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v1.4 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

2.0 S5 (4july)
blocking-b2g 1.4+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified


(Reporter: garvan, Assigned: garvan)




(2 files)

This should be fixed for Dolphin 1.4 release.

nsWifiMonitor::StartWatching creates a 5s repeating timer for scanning, and waits until the first timeout to start scanning. There is no need to wait, scanning can start immediately.

To see the effect on geolocation, open a page like:$samples/Geolocation_Live_Example

It will take 5 sec to get a location, however, if StartWatching was to scan immediately, we can improve this to 1 sec or less.

This also contributes to the performance problem seen here: bug 1028452.
Did you mean to nom this for 1.4? in the blocking b2g flag? The comment you wrote implies that you think this is needed for 1.4.
Flags: needinfo?(gkeeley)
I was planning to get a 2nd opinion from cpeterson as to whether this is a blocker or not, but I'll go ahead and mark it as such. 
This bug was partially responsible for bug 1028452, and there could be other areas of the product that have the same bug (where developers are assuming the geolocation api responds in 1 sec or less). Users of the API should not make this assumption, however, the 5 sec response time is excessive and produces a bad user experience.

I have a patch, will put it up now
blocking-b2g: --- → 1.4?
Flags: needinfo?(gkeeley)
Rather than wait for the 5s timeout to do a first scan, do a first scan immediately.

Doug T. is familiar with this patch, so marking him for review
Attachment #8448062 - Flags: review?(dougt)
blocking-b2g: 1.4? → 1.4+
garvan, after reading the dependent bug 1028452 , I guess this issue is more obvious in 2.0 due the geolocation integration with collections. Confirmed with QA that the lag is obvious. So, as discussed offline, keeping in mind the low risk impact here, lets get this landed on all branches.

(You basically take care of inbbound/central landing and ryanvm can help us with branch uplifts here.)

Also a proactive Ni on :jlorenze  to help verify this once it lands.
Flags: needinfo?(jlorenzo)
Attachment #8448062 - Flags: review?(dougt)
Attachment #8448062 - Flags: review+
Attachment #8448062 - Flags: approval-mozilla-b2g30+
Keywords: checkin-needed

could we get a try link for patch? Thanks!
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.0 S5 (4july)
checkin-needed still for mozilla-aurora (for B2G 2.0) and mozilla-b2g30_v1_4
We have separate bug queries for uplifts. To avoid cluttering up the various queries, please avoid setting checkin-needed additionally.
Keywords: checkin-needed
Verified in dependent bug:
Flags: needinfo?(jlorenzo)
Hi Garvan,
    Could you provide the detailed reproduce steps or video for me to verify this bug?

Thank you!
Flags: needinfo?(gkeeley)
Try load the page from comment 0, and time it. The first load might require 5s for a response, but reloading the page should get a response <5s (1-3s).
Flags: needinfo?(gkeeley)
This issue has been successfully verified on Flame v2.1&2.0.
See attachment: verified_v2.0.mp4.
Reproduce rate: 0/5

1.Send the url "$samples/Geolocation_Live_Example" to device via mail.
2.Open the url first.
3.Record load time:<3s
4.Tap the url again.
5.Record load time:<3s

Flame 2.0 versions:
Gaia-Rev        8d1e868864c8a8f1e037685f0656d1da70d08c06
Build-ID        20141203000201
Version         32.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141203.034550
FW-Date         Wed Dec  3 03:46:01 EST 2014
Bootloader      L1TC00011880

Flame 2.1 versions:
Gaia-Rev        dbaf3e31c9ba9c3436e074381744f2971e15c7bf
Build-ID        20141203001205
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141203.034907
FW-Date         Wed Dec  3 03:49:18 EST 2014
Bootloader      L1TC00011880
You need to log in before you can comment on or make changes to this bug.