187 bytes, text/html
Go to Settings>Bluetooth. Here we observe that the device keeps inquiring for nearby devices. After Inquiry completes, again Inquiry command is sent, and thus the device keeps Inquiring. Even when HOME key is pressed, and when power key is pressed (so that the device goes into suspend mode), the Inquiry doesn't stop.
The state of discovering could be controlled by applications via calling StartDiscovery()/StopDiscovery(). I don't remember that I've ever seen this requirement or scenario defined in UX spec, especially in the case that HOME/POWER key is pressed. The latest UX spec I can find is v11: https://www.dropbox.com/sh/ygwfxk6chpshxdj/gclt7lI4JJ/Apps/Settings/R1_Connectivity_v11.pdf Discovering is a heavy loading procedure. In my opinion, we should let it timed out with a period of time, like 60 or 90 seconds, and enable "Search again" button after discovering is stopped. +needinfo Larissa, We need advice from our UX designer of Settings.
Triage: Blocking on certification problem potential
Yes, let's have it timeout after 90 seconds while the user is on the bluetooth settings page. It should automatically timeout too when the user exits the bluetooth settings page.
Eric, what's your estimate for fixing this?
(In reply to Dietrich Ayala (:dietrich) from comment #4) > Eric, what's your estimate for fixing this? It would be done in Gaia, so I'll let Evelyn to estimate. The modifications would be: (1) shorten the period of discovering time to a more reasonable value (90 secs). (2) timeout and stop discovering whenever leaving Bluetooth(in Settings) page. If you have any questions, please let me know. Thank you. Eric
I'm doing now. Hope I can submit my patch today.
Created attachment 691285 [details] point to https://github.com/mozilla-b2g/gaia/pull/6969 In this patch, I didn't update discovering time, because it's 60 seconds now, it's short enough. I stop discovering nearby devices when Settings app is pushed to the background. Also do some code clean up and error checking.
Comment on attachment 691285 [details] point to https://github.com/mozilla-b2g/gaia/pull/6969 r=me, after fixing stopDiscovery() and manual tests.
Move mozHidden checking out of stopDiscovery() function, create another function for checking instead. Tested and it works. Eric will help on creating a follow-up issue for the problem that Bluetooth defaultAdapter.stopDiscovery() DOM request sometimes won't return back. Commit merged: https://github.com/mozilla-b2g/gaia/commit/ba1f14083f36500cd49397d83e8ddd111684764a
Fixed in https://releases.mozilla.com/b2g/ 20121212 build