Closed
Bug 1074152
Opened 10 years ago
Closed 10 years ago
"Searching for devices" never ends when trying to performing various sharing activities
Categories
(Firefox OS Graveyard :: Bluetooth, defect)
Tracking
(blocking-b2g:2.1+, b2g-v2.0 verified, b2g-v2.0M verified, b2g-v2.1 verified, b2g-v2.2 verified)
People
(Reporter: jlorenzo, Assigned: yrliou)
References
Details
(Keywords: smoketest)
Attachments
(2 files)
46 bytes,
text/x-github-pull-request
|
iliu
:
review+
bajaj
:
approval-gaia-v2.0+
bajaj
:
approval-gaia-v2.1+
jmitchell
:
qa-approval+
|
Details | Review |
5.40 MB,
video/mp4
|
Details |
Build info Gaia-Rev 063de64a4ffc606e931ed7b09e93282713c46eca Gecko-Rev https://hg.mozilla.org/releases/mozilla-aurora/rev/055d46b81ed1 Build-ID 20140929000203 Version 34.0a2 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20140929.033611 FW-Date Mon Sep 29 03:36:22 EDT 2014 Bootloader L1TC10011800 Prerequisite Have at least a contact. Bluetooth should be turned on. STR 1. Open the contact app and then the contact settings 2. Choose "Export contacts" then choose Bluetooth 3. Select a contact to export and tap "export" 4. Once your at the page with "Devices in the area", wait for 2 or 3 minutes Expected results On a Buri, after 60 seconds, the search is ended and you're able to search for devices again by tapping the button at the bottom. Actual results "Search for devices..." is still displayed and the button "Search for device" is not enabled.
Reporter | ||
Comment 1•10 years ago
|
||
(In reply to Johan Lorenzo [:jlorenzo] from comment #0) > "Search for devices..." is still displayed Typo: "Searching for devices..." is still displayed As it's a Bluetooth issue, we need to check against the v123 base image with 2.1, first. If we're not able to repro, no need to check further. If we are, then let's do the regular branch check.
Comment 2•10 years ago
|
||
Hi, that flow it's outside contacts app, in settings, but we do have a specific component for bluetooth staff.
Reporter | ||
Comment 3•10 years ago
|
||
Sorry, I wasn't sure of it. Moving this bug to the BT component.
Component: Gaia::Contacts → Bluetooth
Updated•10 years ago
|
QA Contact: ddixon
Comment 5•10 years ago
|
||
Branch Check Issue DOES occur in Flame 2.2, 2.1, 2.0 and 2.0 Base Image (v180). Device: Flame Master Build ID: 20140728065013 Gaia: 295967a0b824a355ae9d57fb08f3632ed2ad18dd Gecko: d77f6a96ff96 Version: 34.0a1 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------------------------ Device: Flame 2.1 Build ID: 20140928234259 Gaia: 063de64a4ffc606e931ed7b09e93282713c46eca Gecko: 055d46b81ed1 Version: 34.0a2 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 ------------------------------------------------------ Device: Flame 2.0 Build ID: 20140929063300 Gaia: 5c2303ec4e367da060aa1b807d541a6549b3d72a Gecko: d7b2e9cc93f8 Version: 32.0 (2.0) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 ------------------------------------------------------ Flame 2.0 Base Image Note: In the 2.0 branches listed above, an "Export Error" screen is shown after 60 seconds when the phone is searching for bluetooth devices in the area.
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0:
--- → affected
status-b2g-v2.2:
--- → affected
Flags: needinfo?(jmitchell)
Keywords: qawanted
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → joliu
Assignee | ||
Comment 6•10 years ago
|
||
I can reproduce this on 2.0, 2.1, mc. Gallery transfer have the same symptom, too. After investigating it, I found that bluetooth stack finish the discovery before discovery timeout and gecko already dispatch discoverystatechanged event to gaia. However, it seems bluetooth app didn't handle this event, it then issue stopDiscovery to gecko when it exceed the timeout. Since there is no active discovery process, bluetooth stack will return fail and result in entering req.onerror of stopDiscovery. (take master as an example, it will enter https://github.com/mozilla-b2g/gaia/blob/master/apps/bluetooth/js/deviceList.js#L346) And searchAgainBtn will remain disable in this circumstance. ni Ian to provide more info from gaia perspective.
Flags: needinfo?(iliu)
Comment 7•10 years ago
|
||
[Blocking Requested - why for this release]: Regression in functionality that is blocking users from being able to pair their devices. Happens across the board - Gallery - Contacts - Sharing Video, etc.
blocking-b2g: --- → 2.1?
Summary: "Searching for devices" never ends when you export contacts via Bluetooth → "Searching for devices" never ends when trying to performing various sharing activities
Comment 9•10 years ago
|
||
qawanted to check if this worked on v123
Updated•10 years ago
|
Comment 10•10 years ago
|
||
v123 Base Branch Check Issue DOES NOT occur in Flame v123 Base Image (tested branches: 2.2, 2.1, 2.0) Actual Results: After 60 seconds, "Search for devices" button is re-enabled. Device: Flame Master Build ID: 20140923233152 Gaia: ff6dbb006e4e60edba697639aa2a2a199b07069b Gecko: 1e2993c99323 Version: 35.0a1 (Master) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0 Device: Flame 2.1 Build ID: 20140924071252 Gaia: 020e6283a033e8fbcf65e7ed81c5b75ba0095f22 Gecko: 8e9a9df76e89 Version: 34.0a2 Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 Build ID: 20140923195101 Gaia: 263e3b201dca967ec5346e35901aa981ca47dce7 Gecko: 35d791e16d31 Version: 32.0 (2.0) Firmware Version: v123 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 11•10 years ago
|
||
Comment 10 makes it look to be a vendcom issue since this worked in the previous base image.
Comment 13•10 years ago
|
||
duane, can you try full flashing v180 image with 2.0 kk pvtbuilds? this way we can tell if its mozilla code breaking the v180 KK base image or not.
Updated•10 years ago
|
Flags: needinfo?(ddixon)
Comment 14•10 years ago
|
||
(In reply to Tony Chung [:tchung] from comment #13) > duane, can you try full flashing v180 image with 2.0 kk pvtbuilds? this > way we can tell if its mozilla code breaking the v180 KK base image or not. disregard, as this was already done in comment 5. we need jocelyn and ian's feedback if this sounds like a problem with the v180 base image itself. If so, please escalate this to vendor.
Keywords: qawanted
Updated•10 years ago
|
Flags: needinfo?(ddixon)
Assignee | ||
Comment 15•10 years ago
|
||
Note that, flame v123 Base Image is using JB+bluez and v180 we use KK+bluedroid. So it is possible that it only occur in v180 since bt stack is different.
Comment 16•10 years ago
|
||
Per comment 10, I feel strange why the search button is working fine in v123 for a long time(2.0/2.1/2.2). In other words, the event coming time might be different than before.
Assignee | ||
Comment 17•10 years ago
|
||
As I mentioned, v123 is using bluez instead of bluedroid. I just check the behavior on flame+JB(v123), a discoverystatechanged event is reported before timeout as what happened on flame+KK(v180). In other words, the event coming time should be the same. However, in v123 + 2.0/2.1/2.2, UI also didn't update right after this event. It also wail until timeout then call stop discovery. What makes flame(using bluez) and flame-kk(using bluedroid) different is bluedroid will report error if we trying to stop discovery when there isn't an active one while bluez won't complain about it. IMO, we should update UI right after this event, like settings app. Does this make sense to you?
Comment 18•10 years ago
|
||
Ian, you may also want to check bug 945631 for how I did for Settings App.
Comment 19•10 years ago
|
||
(In reply to jocelyn [:jocelyn] from comment #17) > As I mentioned, v123 is using bluez instead of bluedroid. > I just check the behavior on flame+JB(v123), a discoverystatechanged event > is reported before timeout as what happened on flame+KK(v180). > In other words, the event coming time should be the same. Looks like we have to receive discoverystatechanged event for updating search button. Bluetooth app does not implement it yet. > > However, in v123 + 2.0/2.1/2.2, UI also didn't update right after this event. > It also wail until timeout then call stop discovery. > What makes flame(using bluez) and flame-kk(using bluedroid) different is > bluedroid will report error if we trying to stop discovery when there isn't > an active one while bluez won't complain about it. Yes! In my observation, we do stopDiscovery() in the two images. The response is as your mention. JB(v123): callback into onsuccess --> Gaia::Bluetooth app will re-enable search button in this case. KK(v180): callback into onerror --> Gaia::Bluetooth app will disable search button in this case. > > IMO, we should update UI right after this event, like settings app. > Does this make sense to you? Agree with your perspective totally. And the change will be almost same with bug 945631 as Eric's mention in comment 18.
Flags: needinfo?(iliu)
Comment 20•10 years ago
|
||
Jocelyn, this is a Gaia issue. And feel free to assign the issue to me:)
Assignee | ||
Comment 21•10 years ago
|
||
Hi Ian, I have revised bluetooth app based on bug945631. Could you take some time to review this PR? Thanks, Jocelyn
Attachment #8498018 -
Flags: review?(iliu)
Comment 22•10 years ago
|
||
Comment on attachment 8498018 [details] [review] Pull Request - Bug 1074152: Handle discoverystatechanged event in bluetooth app. Looks good for me. After applied the patch with manual test, the search button is working fine on both JB(v123)/KK(v180) build version. Thanks for Jocelyn's help in Gaia side immediately:)
Attachment #8498018 -
Flags: review?(iliu) → review+
Comment 23•10 years ago
|
||
Since the patch is landed, we can close the issue now. Gaia/master: 434aea63526862952975238d26db0aa55b001f4c
Comment 24•10 years ago
|
||
Comment on attachment 8498018 [details] [review] Pull Request - Bug 1074152: Handle discoverystatechanged event in bluetooth app. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): bug 1074152 [User impact] if declined: Cannot re-trigger to search bluetooth devices via search button. [Testing completed]: Passed on try-server. [Risk to taking this patch] (and alternatives if risky): Low [String changes made]: None
Attachment #8498018 -
Flags: approval-gaia-v2.1?
Comment 25•10 years ago
|
||
Flagging qawanted to verify fix this by pulling latest Master Gaia and try this patch for the approval-gaia-v2.1? flag.
Comment 26•10 years ago
|
||
Confirming that this issue is fixed with the patch. Actual Results: The "Search for devices" button is re-enabled after about 15 seconds. Device: Flame Master Build ID: 20141001060621 Gaia: da6c4f46499198950b1ef520a19367d51cb60b8b Gecko: 835ef55e175e Version: 35.0a1 (Master) Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Updated•10 years ago
|
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Comment 27•10 years ago
|
||
I think we did this wrong, the patch needed to be applied to 2.1
Comment 28•10 years ago
|
||
(In reply to Peter Bylenga [:PBylenga] from comment #25) > Flagging qawanted to verify fix this by pulling latest Master Gaia and try > this patch for the approval-gaia-v2.1? flag. Confirming that 2.1 is verified fixed with the patch implemented. Actual Results: The "Search for devices" button is re-enabled after about 15 seconds. Device: Flame Master Build ID: 20141001123325 Gaia: da6c4f46499198950b1ef520a19367d51cb60b8b Gecko: 4ff49aa32213 Version: 34.0a2 Firmware Version: v180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0
Updated•10 years ago
|
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Keywords: verifyme
Comment 29•10 years ago
|
||
Please nominate this patch for Gaia v2.1 approval when you get a chance :)
Flags: needinfo?(joliu)
Target Milestone: --- → 2.1 S6 (10oct)
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #29) > Please nominate this patch for Gaia v2.1 approval when you get a chance :) I think Comment 24 already did.
Comment 32•10 years ago
|
||
Hi Bhavana, In case you might not notice, a friendly reminder that Ian has already requested for approval-gaia-v2.1.
Flags: needinfo?(bbajaj)
Comment 33•10 years ago
|
||
Comment on attachment 8498018 [details] [review] Pull Request - Bug 1074152: Handle discoverystatechanged event in bluetooth app. Should have flipped this to + when Duane verified this
Attachment #8498018 -
Flags: qa-approval+
Updated•10 years ago
|
Flags: needinfo?(bbajaj)
Updated•10 years ago
|
Attachment #8498018 -
Flags: approval-gaia-v2.1? → approval-gaia-v2.1+
Comment 34•10 years ago
|
||
v2.1: https://github.com/mozilla-b2g/gaia/commit/d573e8f91cfe9c387c850464184ff00f134e644b
Comment 35•10 years ago
|
||
Comment on attachment 8498018 [details] [review] Pull Request - Bug 1074152: Handle discoverystatechanged event in bluetooth app. NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings. [Approval Request Comment] [Bug caused by] (feature/regressing bug #): bug 1074152 [User impact] if declined: Cannot re-trigger to search bluetooth devices via search button. Per comment 5 and comment 6, the issue is happened on 2.0 Base Image (v180). [Testing completed]: Passed on try-server. [Risk to taking this patch] (and alternatives if risky): Low [String changes made]: None
Attachment #8498018 -
Flags: approval-gaia-v2.0?
Updated•10 years ago
|
Attachment #8498018 -
Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
Comment 36•10 years ago
|
||
v2.0: https://github.com/mozilla-b2g/gaia/commit/ed674117441c77896e3ae7073b7fe12eb736315e
Comment 37•10 years ago
|
||
v2.0m: https://github.com/mozilla-b2g/gaia/commit/ed674117441c77896e3ae7073b7fe12eb736315e
status-b2g-v2.0M:
--- → fixed
Comment 38•10 years ago
|
||
VERIFIED FIXED on v2.1 and v2.0. Environmental Variables: Device: Flame 2.1 KK (319 MB) BuildID: 20141011000201 (full flash) Gaia: f5d4ff60ffed8961f7d0380ada9d0facfdfd56b1 Gecko: d813d79d3eae Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Device: Flame 2.0 BuildID: 20141011000202 Gaia: 6effca669c5baaf6cd7a63c91b71a02c6bd953b3 Gecko: 54ec9cb26b59 Gonk: 52c909e821d107d414f851e267dedcd7aae2cebf Version: 32.0 (2.0) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 The search is ended and the search again button becomes enabled.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Comment 39•10 years ago
|
||
Leaving verifyme for 2.0M verification. We do not have that particular device to check this.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Updated•10 years ago
|
QA Contact: ddixon
Comment 40•10 years ago
|
||
Verify passed, this issue can't be repro on Woodduck 2.0. Attached: Verify_Woodduck_BTsearch.mp4 Reproducing rate: 0/5 Gaia-Rev ee5cf148b4c546beea9bfb799d2a3ee62074957d Gecko-Rev 73601b71861cbc2f180c4d2653cec3e9fbb39db5 Build-ID 20141114050313 Version 32.0
Comment 41•10 years ago
|
||
You need to log in
before you can comment on or make changes to this bug.
Description
•