Closed Bug 1032015 Opened 5 years ago Closed 5 years ago
Wifi Monitor Gonk takes 5 sec to start scanning, and geolocation must wait
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: https://mdn.mozillademos.org/en-US/docs/WebAPI/Using_geolocation$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.
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?
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
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.
Hi, could we get a try link for patch? Thanks!
Try link: https://tbpl.mozilla.org/?tree=Try&rev=7b82d907acb6 Once completed, builds and logs will be available at: https://email@example.com
Status: NEW → RESOLVED
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.
Verified in dependent bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1028452#c32
Hi Garvan, Could you provide the detailed reproduce steps or video for me to verify this bug? Thank you!
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).
This issue has been successfully verified on Flame v2.1&2.0. See attachment: verified_v2.0.mp4. Reproduce rate: 0/5 STR: 1.Send the url "https://mdn.mozillademos.org/en-US/docs/WebAPI/Using_geolocation$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 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/29222e215db8 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 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/ebce587d2194 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.