861085 - [OPEN_][Bluetooth] It can not toggle again after turning on BT

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[lv]

Steps to reproduce:
1. go into setting-bluetooth;
2. tap button to turn on BT;
EXPECTED:
1.Bluetooth is turned on, and can search some BT device;
ACTUAL:
1.the button behind Bluetooth is shown gray(see screenshot);
2.it can not search any BT devices.

Comment 1

[lv]

Attachment: screenshot

Comment 2

[lv]

build information:
20130412
gaia commit:
c844c2c Bug [Bug 857177] [Browser] add storage permission (cherry picked from commit 35f364d2b734db12335e20f6b39e57617325c6e8)
gecko commit:
131bdd1 Bug 858674 - Tweak SQLite pragmas on mobile devices for space savings. r=khuey, a=tef+

Comment 3

[Kai-Chih Hu [:khu]]

Eric, is this something you could help? Thanks!

Comment 4

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

(In reply to [e-mail] from comment #2)
> build information:
> 20130412
> gaia commit:
> c844c2c Bug [Bug 857177] [Browser] add storage permission (cherry picked
> from commit 35f364d2b734db12335e20f6b39e57617325c6e8)
> gecko commit:
> 131bdd1 Bug 858674 - Tweak SQLite pragmas on mobile devices for space
> savings. r=khuey, a=tef+

This should have been fixed in bug 847851. Although your Gaia seems to be later than mine, would you mind checking if the solution of bug 847851 exists in your branch? Is it 100% reproduciable? Because I've tried on/off more than 30 times and it still worked well.

I can only think of one condition would make this happen: |make reset-gaia| or |make install-gaia| when Bluetooth is already on. Did you do this?

Comment 5

[lv]

I try in my SW, and the issue that mentions in bug 847851 can be reproduced. The situation is the same. When I kill setting APP and go into Bluetooth again, it can search BT device successful. But after I restart the Phone, it can reproduce again.

Comment 6

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

(In reply to [e-mail] from comment #5)
> I try in my SW, and the issue that mentions in bug 847851 can be reproduced.
> The situation is the same. When I kill setting APP and go into Bluetooth
> again, it can search BT device successful. But after I restart the Phone, it
> can reproduce again.

When you say "can reproduce again", do you mean that the very first time you tried to re-enable bluetooth must fail? Or do you need to enable/disable Bluetooth several times?

Comment 7

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

I recorded a video and I can keep tapping the switch to enable/disable Bluetooth for about 1 minute.

Video location: https://www.dropbox.com/s/a78cg0dpqauaivc/Bug-861085.mp4
BuildID: 20130411070205

Comment 8

[William Hsu [:whsu]]

Hi, all,

There have a condition that can easy to reproduce this case. while I flash a new build to unagi device then enable bluetooth(first time), the bluetooth function will hang there.
Please see the attachment.

* Test build: (Mozilla-b2g18_v1_0_1-unagi-eng/2013-04-12-23-02-03)
  - Mercurial-Information:
    + Gecko revision="91fc54411a34"
    + Gaia revision="058522d169c0"
  - Git-Information
    + Gecko revision="d7a6db4fc48e4091da842f408e69f969a0e704ec"
    + Gaia revision="3e7dda88950ae09166109783adea8181eb857d21"


Best Regards,
William

Comment 9

[William Hsu [:whsu]]

Attach the video link:
https://dc1.safesync.com/LMjKLMQd/VIDEO0056.3gp?a=lqX7Hld2Jeg

Comment 11

[Arthur Chen [:arthurcc][inactive after 6/30]]

Michael provided steps with high reproduce rate in bug 861433:

# Make sure settings is not running: long-press+home, click X on Settings apps if present
# Click on Settings then quickly...
# Click on Bluetooth '''before''' the subtext is populated (eg. "No devices paired", "Disabled, etc.)
# Toggle the Bluetooth

Expected: checkbox will be toggled and disabled, then shortly re-enabled
Seen: checkbox remains disabled

Killing the Settings app and restarting and avoiding above race condition shows the BT stack is behaving fine.

Comment 12

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

This bug may happen when each of two situations matches:

(1) Enable Bluetooth, then do |make reset-gaia| or any other operation which would clear mozSettings. This is what William was talking about in comment 8.
(2) The scenario described in comment 11

For case (1), it's not easy to be reproduced by normal users. The root cause is that "mozSettings does not represent real Bluetooth state". Bluetooth was still alive, but mozSettings was cleared to 0.

The patch is almost ready for case (1). I'll upload later.

For case (2), it seems like a Gaia bug. Gina told me that it's not too hard to reproduce. So maybe Evelyn or Arthur can help.

Comment 13

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

Attachment: patch 1: v1: enable/disable Bluetooth based on mozSettings at startup

= Basic Information =
|make reset-gaia| makes b2g process restart, and mozSettings will be cleared to 0 even if bluetoothd is still alive. When b2g process restarts, gBluetoothService->mEnabled will be initialized to false. Therefore gBluetoothService->IsEnabled() will always return false as well.

= Problem =
The condition check, "if(mEnabled == gBluetoothService->IsEnabled())" in ToggleBtTask, always returns true after |make reset-gaia|. In this case, Bluetooth won't be disabled even if ToggleBtTask::mEnabled is false. That's why we need a IsEnabledInternal to get the real state of Bluetooth firmware.

Comment 14

[Gina Yeh [:gyeh] [:ginayeh]]

(In reply to Eric Chou [:ericchou] [:echou] from comment #12)
> 
> For case (2), it seems like a Gaia bug. Gina told me that it's not too hard
> to reproduce. So maybe Evelyn or Arthur can help.

I usually have this issue on debug build. (Obviously, it's a timing issue)

Comment 15

[Gina Yeh [:gyeh] [:ginayeh]]

Comment on attachment 737441 [details] [diff] [review]
patch 1: v1: enable/disable Bluetooth based on mozSettings at startup

Review of attachment 737441 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with nits addressed and question answered.

::: dom/bluetooth/gonk/BluetoothGonkService.cpp
@@ +160,5 @@
> +  }
> +
> +  return (sBluedroidFunctions.bt_is_enabled() == 1);
> +}
> +

Question: Can we re-use this function in BluetoothGonkService::StartStopGonkBluetooth() ?

::: dom/bluetooth/gonk/BluetoothGonkService.h
@@ +37,2 @@
>  public:
>    /** 

nit: Please help to remove trailing space.

@@ +43,4 @@
>     */
>    virtual nsresult StartInternal();
>  
>    /** 

nit: Please help to remove trailing space.

Comment 16

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

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #15)
> Comment on attachment 737441 [details] [diff] [review]
> patch 1: v1: enable/disable Bluetooth based on mozSettings at startup
> 
> Review of attachment 737441 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> r=me with nits addressed and question answered.
> 
> ::: dom/bluetooth/gonk/BluetoothGonkService.cpp
> @@ +160,5 @@
> > +  }
> > +
> > +  return (sBluedroidFunctions.bt_is_enabled() == 1);
> > +}
> > +
> 
> Question: Can we re-use this function in
> BluetoothGonkService::StartStopGonkBluetooth() ?
> 

These two are slightly different: In order to make things easier, function BluetoothGonkService::IsEnabledInternal() returns only boolean. However, sBluedroidFunctions.bt_is_enabled() returns int and we do check if the returned value is 1, 0, or -1 in StartStopGonkBluetooth(). I prefer leave it as it is.

Comment 17

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

https://hg.mozilla.org/projects/birch/rev/e5de739f53ba

Please don't close this bug because we have to fix case (2) mentioned in comment 12. Thanks.

Comment 18

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

Handing over to Arthur for seeking the root cause of case (2).

Comment 19

[Arthur Chen [:arthurcc][inactive after 6/30]]

Test with:
 v1-train (https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi/2013/04/2013-04-15-23-02-05/)
 v1.0.1 (https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18_v1_0_1-unagi/2013/04/2013-04-15-23-02-02/)

Only v1.0.1 failed. It seems like case 2 has been resolved in bug 847851 but not uplifted to v1.0.1 yet.

Comment 20

[William Hsu [:whsu]]

Hi, all,

Thanks for Eric provided the detail information.
As I test the V1.1.0 on unagi and leo device, this bug cannot reproduce.

Test build:
* Mozilla-b2g18-unagi & v1-train (2013-04-15-23-02-05)
  - Mercurial-Information:
    + Gecko revision="5eb76dd7c2a4"
    + Gaia revision="ef564693c977"
  - Git-Information
    + Gecko revision="d8364b00a36d4d365c32d212d59c4134945a15b0"
    + Gaia revision="a7ecc7446b3a15cd3aed1490080de77b3bbdfe6e"

* Mozilla-b2g18-leo & v1-train (2013-04-15-23-02-05)
  - Mercurial-Information:
    + Gecko revision="5eb76dd7c2a4"
    + Gaia revision="ef564693c977"
  - Git-Information
    + Gecko revision="d8364b00a36d4d365c32d212d59c4134945a15b0"
    + Gaia revision="a7ecc7446b3a15cd3aed1490080de77b3bbdfe6e"


Thanks!

Comment 21

[Arthur Chen [:arthurcc][inactive after 6/30]]

Thanks William. Eric has already resolved case 1. Let's use bug 847851 as the follow up of case 2.

Comment 22

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

(In reply to Arthur Chen [:arthurcc] from comment #21)
> Thanks William. Eric has already resolved case 1. Let's use bug 847851 as
> the follow up of case 2.

Leave it open for sheriff tracking patches.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e5de739f53ba

Don't forget to add [fixed-in-birch] to the whiteboard when you land there.

Comment 24

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

(In reply to Ryan VanderMeulen [:RyanVM] from comment #23)
> https://hg.mozilla.org/mozilla-central/rev/e5de739f53ba
> 
> Don't forget to add [fixed-in-birch] to the whiteboard when you land there.

Ah, got it. Thanks.

Comment 25

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-b2g18/rev/ebe2a16277ae
https://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/6bac24e14538

Comment 26

[Sreenidhi]

Tested in Inari V1.0.1 using the following build :

Gecko  http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/0c76ef5f8677
Gaia   64d5096e1746bd4b08bc1bf69844d164ac961970
BuildID 20130418070206
Version 18.0

Cannot reproduce this bug

Comment 27

[Sreenidhi]

Tested on an Inari with the following build information :

Build ID : 20130422054646
Git Commit Info : 2013-04-21 21:19:35
Gaia Repo : 55f009ff476687958decea8d9cc15791... (ellipsis at the end)

The above issue is not re-occurring. Henceforth, Verified.