1074152 - "Searching for devices" never ends when trying to performing various sharing activities

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Johan Lorenzo [:jlorenzo]]

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.

Comment 1

[Johan Lorenzo [:jlorenzo]]

(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

[Francisco Jordano [:arcturus] [:francisco]]

Hi,

that flow it's outside contacts app, in settings, but we do have a specific component for bluetooth staff.

Comment 3

[Johan Lorenzo [:jlorenzo]]

Sorry, I wasn't sure of it. Moving this bug to the BT component.

Comment 4

[Johan Lorenzo [:jlorenzo]]

QA wanted as per comment 1.

Comment 5

[Duane Dixon [:ddixon]]

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.

Comment 6

[Jocelyn Liu [:jocelyn] [:joliu]]

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.

Comment 7

[Marcia Knous [:marcia]]

[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.

Comment 9

[Marcia Knous [:marcia]]

qawanted to check if this worked on v123

Comment 10

[Duane Dixon [:ddixon]]

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

Comment 11

[Marcia Knous [:marcia]]

Comment 10 makes it look to be a vendcom issue since this worked in the previous base image.

Comment 12

[Tony Chung [:tchung]]

blocking 2.1+.  this is a smoketest blocker

Comment 13

[Tony Chung [:tchung]]

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.

Comment 14

[Tony Chung [:tchung]]

(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.

Comment 15

[Jocelyn Liu [:jocelyn] [:joliu]]

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

[[e-mail], [e-mail]]

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.

Comment 17

[Jocelyn Liu [:jocelyn] [:joliu]]

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

[Eric Chou [:ericchou] [:echou]]

Ian, you may also want to check bug 945631 for how I did for Settings App.

Comment 19

[[e-mail], [e-mail]]

(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.

Comment 20

[[e-mail], [e-mail]]

Jocelyn, this is a Gaia issue. And feel free to assign the issue to me:)

Comment 21

[Jocelyn Liu [:jocelyn] [:joliu]]

Attachment: Pull Request - Bug 1074152: Handle discoverystatechanged event in bluetooth app.

Hi Ian,

I have revised bluetooth app based on bug945631.
Could you take some time to review this PR?

Thanks,
Jocelyn

Comment 22

[[e-mail], [e-mail]]

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:)

Comment 23

[[e-mail], [e-mail]]

Since the patch is landed, we can close the issue now.

Gaia/master:  434aea63526862952975238d26db0aa55b001f4c

Comment 24

[[e-mail], [e-mail]]

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

Comment 25

[Peter Bylenga [:PBylenga]]

Flagging qawanted to verify fix this by pulling latest Master Gaia and try this patch for the approval-gaia-v2.1? flag.

Comment 26

[Duane Dixon [:ddixon]]

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

Comment 27

[Joshua Mitchell (Inactive)]

I think we did this wrong, the patch needed to be applied to 2.1

Comment 28

[Duane Dixon [:ddixon]]

(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

Comment 29

[Ryan VanderMeulen [:RyanVM]]

Please nominate this patch for Gaia v2.1 approval when you get a chance :)

Comment 30

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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 31

[Eric Chou [:ericchou] [:echou]]

Shawn is right. Clear ni for Jocelyn.

Comment 32

[Eric Chou [:ericchou] [:echou]]

Hi Bhavana,

In case you might not notice, a friendly reminder that Ian has already requested for approval-gaia-v2.1.

Comment 33

[Joshua Mitchell (Inactive)]

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

Comment 34

[Ryan VanderMeulen [:RyanVM]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/d573e8f91cfe9c387c850464184ff00f134e644b

Comment 35

[[e-mail], [e-mail]]

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

Comment 36

[Ryan VanderMeulen [:RyanVM]]

v2.0: https://github.com/mozilla-b2g/gaia/commit/ed674117441c77896e3ae7073b7fe12eb736315e

Comment 37

[Kai-Zhen Li [:seinlin][:kli]]

v2.0m: https://github.com/mozilla-b2g/gaia/commit/ed674117441c77896e3ae7073b7fe12eb736315e

Comment 38

[Rachel Pribble [:rpribble]]

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.

Comment 39

[KTucker [:KTucker][Inactive 3/4/2016]]

Leaving verifyme for 2.0M verification. We do not have that particular device to check this.

Comment 40

[Coler]

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

[Coler]

Attachment: Verify_Woodduck_BTsearch.MP4