Closed
Bug 1011326
Opened 10 years ago
Closed 10 years ago
[MADAI][Bluetooth] The search button is still "searching..." even after discovery completed.
Categories
(Firefox OS Graveyard :: Bluetooth, defect, P3)
Tracking
(blocking-b2g:1.4+, b2g-v1.4 fixed, b2g-v2.0 fixed)
People
(Reporter: rapbong, Assigned: echou)
References
()
Details
(Whiteboard: [CR 668500] [LibGLA, Mantis][p=2])
Attachments
(1 file)
97.73 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.131 Safari/537.36 Steps to reproduce: 1. Entering the Bluetooth setting menu 2. Try to the discovery start("Search for devices" button) 3. Waiting until discovery completed Actual results: Search button is still disabled Expected results: Search button is enabled after discovery completed
Reporter | ||
Updated•10 years ago
|
blocking-b2g: --- → 1.4?
OS: All → Gonk (Firefox OS)
Priority: -- → P3
Hardware: All → ARM
Whiteboard: [LibGLA, Mantis]
Reporter | ||
Comment 1•10 years ago
|
||
Dear Mozilaa Engineer. This case isn't updating the search button. The discovery completed event is occurred in the bluedroid. And discovery_state_changed_cb is called but the return value don't send to the gaia layer. Because the sChangedDiscoveryRunnableArray is the empty array in the DiscoveryStateChangedCallback. Could you help me to solve this case? Thank you for your support.
Eric, This looks like bug 942104, shall we rebase the patch again?
Flags: needinfo?(echou)
Assignee | ||
Comment 3•10 years ago
|
||
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #2) > Eric, > This looks like bug 942104, shall we rebase the patch again? Yes, we should restart the implementation of bug 942104. Thanks for reporting this.
Depends on: 942104
Flags: needinfo?(echou)
Comment 4•10 years ago
|
||
Eric, Can you please weigh in on risk analysis the same?
Flags: needinfo?(echou)
Assignee | ||
Comment 5•10 years ago
|
||
Hi Preeti, (In reply to Preeti Raghunath(:Preeti) from comment #4) > Eric, > > Can you please weigh in on risk analysis the same? This is a bug that we need to solve with no doubt, otherwise Bluetooth discovery would not be able to be re-triggered. Actually we have already opened 2 issues, bug 942104(gecko part) and bug 945631(Gaia part), to fix the same problem. Once they get fixed, this issue would be gone as well. Patches for Bug 942104 all got r+ this morning, and I've already had a solution for bug 945631 as well, so "low-risk" would be the answer from my point of view.
Assignee: nobody → echou
Depends on: 945631
Flags: needinfo?(echou)
Whiteboard: [LibGLA, Mantis] → [LibGLA, Mantis][ETA:5/23][p=2]
Updated•10 years ago
|
blocking-b2g: 1.4? → 1.4+
Updated•10 years ago
|
Whiteboard: [LibGLA, Mantis][ETA:5/23][p=2] → [CR 668500] [LibGLA, Mantis][ETA:5/23][p=2]
Updated•10 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 6•10 years ago
|
||
(In reply to Eric Chou [:ericchou] [:echou] from comment #5) > Hi Preeti, > > (In reply to Preeti Raghunath(:Preeti) from comment #4) > > Eric, > > > > Can you please weigh in on risk analysis the same? > > This is a bug that we need to solve with no doubt, otherwise Bluetooth > discovery would not be able to be re-triggered. Actually we have already > opened 2 issues, bug 942104(gecko part) and bug 945631(Gaia part), to fix > the same problem. Once they get fixed, this issue would be gone as well. > Patches for Bug 942104 all got r+ this morning, and I've already had a > solution for bug 945631 as well, so "low-risk" would be the answer from my > point of view. Both blockers have been resolved. I just tried the latest gecko:m-c/gaia:master and I can confirm that this issue has been fixed. 1.4 should be fixed as well once bug 945631 is uplifted. Please re-test after that. Thanks.
Assignee | ||
Comment 7•10 years ago
|
||
Hi Ilbeom, Bug 945631 has been uplifted to 1.4. Please confirm if this issue has been fixed as well. Thank you.
Flags: needinfo?(rapbong)
:echou, issue is still present on v1.4 even after landing Bug 945631 STR is same as #comment 0 Gaia UI re-activate "search for devices" icon only for 60 secs delay. It takes 60 sec delay even if bluetooth search is completed within 30 secs.
Updated•10 years ago
|
Flags: needinfo?(rapbong) → needinfo?(echou)
Assignee | ||
Comment 9•10 years ago
|
||
(In reply to Tapas Kumar Kundu from comment #8) > :echou, issue is still present on v1.4 even after landing Bug 945631 > > STR is same as #comment 0 > > Gaia UI re-activate "search for devices" icon only for 60 secs delay. It > takes 60 sec delay even if bluetooth search is completed within 30 secs. I just flashed the latest 1.4 gecko/gaia to my Nexus 5 (because I need a device running Bluedroid) and gave it a test, it looked good. The search button was lighted again once the search was done. Could you please double check that patches for 942104 and 945631 are in the codebase you use? Besides, you mentioned that on your device Bluetooth search is completed within '30' seconds, which is different from Android's default(12 secs). I was wondering if CAF modified the length of inquiry.
Flags: needinfo?(echou) → needinfo?(tkundu)
(In reply to Eric Chou [:ericchou] [:echou] from comment #9) > (In reply to Tapas Kumar Kundu from comment #8) > > :echou, issue is still present on v1.4 even after landing Bug 945631 > > > > STR is same as #comment 0 > > > > Gaia UI re-activate "search for devices" icon only for 60 secs delay. It > > takes 60 sec delay even if bluetooth search is completed within 30 secs. > > I just flashed the latest 1.4 gecko/gaia to my Nexus 5 (because I need a > device running Bluedroid) and gave it a test, it looked good. The search > button was lighted again once the search was done. Could you please double > check that patches for 942104 and 945631 are in the codebase you use? > > Besides, you mentioned that on your device Bluetooth search is completed > within '30' seconds, which is different from Android's default(12 secs). I > was wondering if CAF modified the length of inquiry. Thanks for the info that it is working in bluez. I am just checking with my colleague on this. It may be that gaia/gecko bug is fixed but bludroid bug is causing some delay. I will confirm and update here asap.
Reporter | ||
Comment 11•10 years ago
|
||
(In reply to Eric Chou [:ericchou] [:echou] from comment #7) > Hi Ilbeom, > > Bug 945631 has been uplifted to 1.4. Please confirm if this issue has been > fixed as well. Thank you. Dear eric. I checked out your solution and the search button is very well changed. Thanks you for your support.
Assignee | ||
Comment 12•10 years ago
|
||
(In reply to ILBEOM KIM from comment #11) > (In reply to Eric Chou [:ericchou] [:echou] from comment #7) > > Hi Ilbeom, > > > > Bug 945631 has been uplifted to 1.4. Please confirm if this issue has been > > fixed as well. Thank you. > > Dear eric. > > I checked out your solution and the search button is very well changed. > > Thanks you for your support. Good to know. :)
Assignee | ||
Comment 13•10 years ago
|
||
(In reply to Tapas Kumar Kundu from comment #10) > (In reply to Eric Chou [:ericchou] [:echou] from comment #9) > > (In reply to Tapas Kumar Kundu from comment #8) > > > :echou, issue is still present on v1.4 even after landing Bug 945631 > > > > > > STR is same as #comment 0 > > > > > > Gaia UI re-activate "search for devices" icon only for 60 secs delay. It > > > takes 60 sec delay even if bluetooth search is completed within 30 secs. > > > > I just flashed the latest 1.4 gecko/gaia to my Nexus 5 (because I need a > > device running Bluedroid) and gave it a test, it looked good. The search > > button was lighted again once the search was done. Could you please double > > check that patches for 942104 and 945631 are in the codebase you use? > > > > Besides, you mentioned that on your device Bluetooth search is completed > > within '30' seconds, which is different from Android's default(12 secs). I > > was wondering if CAF modified the length of inquiry. > > Thanks for the info that it is working in bluez. My previous comment actually meant 'it's working in bluedroid', however BlueZ should work as well. (Comment 11 shows that bluedroid does work) > I am just checking with my > colleague on this. It may be that gaia/gecko bug is fixed but bludroid bug > is causing some delay. I will confirm and update here asap. Thanks. :)
(In reply to Eric Chou [:ericchou] [:echou] (GSMA MAE @ Shanghai, 6/10 ~ 6/13) from comment #13) We found a fix for it in bluedroid stack . Fix will land in latest bluedroid repo [1] soon. [1] https://www.codeaurora.org/cgit/quic/la/platform/external/bluetooth/bluedroid/log/?h=b2g_kk_3.5
Flags: needinfo?(tkundu)
Assignee | ||
Comment 15•10 years ago
|
||
(In reply to Tapas Kumar Kundu from comment #14) > (In reply to Eric Chou [:ericchou] [:echou] (GSMA MAE @ Shanghai, 6/10 ~ > 6/13) from comment #13) > > We found a fix for it in bluedroid stack . Fix will land in latest bluedroid > repo [1] soon. > > [1] > https://www.codeaurora.org/cgit/quic/la/platform/external/bluetooth/ > bluedroid/log/?h=b2g_kk_3.5 Hi Tapas, Just a friendly reminder: please close this issue once your fix lands and has been verified. Thanks.
Updated•10 years ago
|
status-b2g-v1.4:
--- → fixed
status-b2g-v2.0:
--- → fixed
Whiteboard: [CR 668500] [LibGLA, Mantis][ETA:5/23][p=2] → [CR 668500] [LibGLA, Mantis][p=2]
Target Milestone: --- → 2.0 S3 (6june)
This test case needs to be updated https://moztrap.mozilla.org/manage/case/3499/ to address this bug.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Comment 17•10 years ago
|
||
Test case updated in moztrap: https://moztrap.mozilla.org/manage/case/3499/
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: in-moztrap?(dharris)
Flags: in-moztrap+
You need to log in
before you can comment on or make changes to this bug.
Description
•