Description: When turning Bluetooth OFF/ON, the device name will disappear, but still able to be connected with another device and recognized by the previous name Device: Buri v1.2 COM RIL BuildID: 20131025004000 Gaia: 606517ceafe0950c2b89822d5f13353743334f2c Gecko: 5eabd267ef04 Version: 26.0a2 RIL Version: 01.02.00.019.082 Firmware Version: US_20131015 Notes: Repro frequency: 100% Like to the failed TC: https://moztrap.mozilla.org/manage/cases/?filter-id=6935 See attached: Video

The issue doesn't reproduce on the latest 1.1 COM RIL Device: Leo 1.1 COM RIL BuildID: 20131030041204 Gaia: 39b0203fa9809052c8c4d4332fef03bbaf0426fc Gecko: 41c15ddb7216 Version: 18.0 Firmware Version:V10c RIL Version: 01.01.00.019.264

Steps to reproduce: 1) Open "Settings" from the home screen 2) Navigate into "Bluetooth" 3) Verify the "Bluetooth" has some name 4) Toggle the "Bluetooth" OFF and then return to "ON"

This issue started to occur on Buri 1.2 Build ID: 20130827040201 Gaia 599214a0f41eece076dc83cd85f5b27f8cfe67f2 SourceStamp e42dce3209da BuildID 20130827040201 Version 26.0a1 Last working Buri 1.2 Build ID: 20130826163255 Gaia 23343e6ea3cc59c3ab0ac9188aaa657bd11da4fd SourceStamp 14b1e8c2957e BuildID 20130826163255 Version 26.0a1

I don't understand what this bug is & what the impact of it is. Can you clarify this a bit better?

The issue is when the device has a name for an example "AAA" and a user is turning "Bluetooth" device OFF and then switching back to "ON", the Bluetooth's name disappears and the device name field is empty.

So if I understand this bug, flipping this pref off & on, we connect to the previous bluetooth headset, but the device name is reported as nothing.

triage: koi+ for regression

Let me take a look. Thanks for reporting.

I tested with the latest build for buri and it works well. Gaia a788ea1a3e04716938bd41a559c36a831cf1190b BuildID 20131030004003 Version 26.0a2 Add keyword "qawanted" for further verification. Thanks.

From the attached video, the device name is shown at the beginning of turning Bluetooth on. However, the name is erased somehow after a few seconds. Although I had no luck to reproduce it, it should be a gaia issue.

I downloaded the build from pvt and tried to full flash my phone again (./flash.sh -f), and I found I can reproduce the bug... :|

I'd like to point out that no name is shown when enabling Bluetooth for the first time.

I was able to successfully reproduce this issue on Buri 1.2 Build ID: 20131031004003 Gaia df049e3177ced0ca493ff0d192c65f18392bb462 SourceStamp 93eafd042c1c BuildID 20131031004003 Version 26.0 Bluetooth name is erased when turning bluetooth OFF then ON.

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #14) > I'd like to point out that no name is shown when enabling Bluetooth for the > first time. Well right, there's no bluetooth device paired with at that point. What's happening in this bug is bluetooth is being re-enabled, we pair with the device we paired with previously, but we lost the device name in the process.

Ian, could you talk to Gina and see if Settings app is at fault here?

Sure, I'm able to reproduce the issue on Mozilla-Central + Gaia/master. Trying to find out the root cause.

Hi Gina, After added some log in settings/js/bluetooth.js, there is no value in the "defaultAdapter.name" sometimes. My steps as following: 1) Click "Rename my device" button and type in "ian-inari" The value is set successfully. But I see an error log as following. I'm not sure that is relative with the issue. ======================================================================================================== E/GeckoConsole( 648): [JavaScript Error: "NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [inIDOMUtils.setContentState]" {file: "chrome://global/content/BrowserElementPanning.js" line: 465}] ======================================================================================================== 2) Re-enable Bluetooth from off to on. At this section, Gaia::settings app will setTimeout to get device name via "defaultAdapter.name" while doing initWithAdapter. And sometimes there is no value in it. ======================================================================================================== E/GeckoConsole( 819): Content JS LOG at app://settings.gaiamobile.org/js/bluetooth.js:187 in initial/<: --> initial(): defaultAdapter.name = ======================================================================================================== Ref: https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/js/bluetooth.js#L186 Since the value is set successfully, I guess the issue might be happened at Gecko side.

Thanks, Ian. (In reply to Ian Liu [:ianliu] from comment #19) > 1) Click "Rename my device" button and type in "ian-inari" > The value is set successfully. But I see an error log as following. I'm not > sure that is relative with the issue. > ============================================================================= > =========================== > E/GeckoConsole( 648): [JavaScript Error: "NS_ERROR_FAILURE: Component > returned failure code: 0x80004005 (NS_ERROR_FAILURE) > [inIDOMUtils.setContentState]" {file: > "chrome://global/content/BrowserElementPanning.js" line: 465}] > ============================================================================= > =========================== It doesn't like a related issue, so just ignore it ;) > 2) Re-enable Bluetooth from off to on. At this section, Gaia::settings app > will setTimeout to get device name via "defaultAdapter.name" while doing > initWithAdapter. > And sometimes there is no value in it. > ============================================================================= > =========================== > E/GeckoConsole( 819): Content JS LOG at > app://settings.gaiamobile.org/js/bluetooth.js:187 in initial/<: --> > initial(): defaultAdapter.name = > ============================================================================= > =========================== It makes sense to me. That's why the name is shown at the beginning and then erased. Let me check Gecko part and I'll keep you updated.

Seems like a timing issue :| Let me figure out a solution... Thanks for your help again, Ian.

Here's some details for Gecko part. When turning on Bluetooth, BluetoothManager.GetDefaultAdapter() is invoked and this async call returns an instance of adapter with all attributes including Name. The implementation of GetDefaultAdapter could be divided into parts: 1. Get the object path of default adapter from BlueZ first 2. Query all properties of the adapter. 3. Create an instance of adapter with these properties. 4. Receive event PropertyChange with correct adapter name and update values of all instances of adapter. Note that, in step 2, the property name returned by BlueZ is always null.

I'd like to correct the last sentence in comment 22. The property name returned by BlueZ is *sometimes* null. If we received event PropertyChange before querying all properties, the name would be correct. (4 -> 1 -> 2 -> 3)

Yes, the symptom is happened sometimes in comment 19.

I think the issue is emerged after landing bug 923647. It's not the root cause, and we still need to figure out a solution.

The problem occurred in the following sequence: 1 -> 2 (the adapter name is null) -> 4 -> 3 (create an adatper with null name) When we received event PropertyChange, we broadcast the message to all instances of adapter. However, no instance is created at that time. So, the message is just ignored.

I think we can hold those PropertyChange events for a while and then broadcast. What do you think, Eric?

I can reproduce it on unagi with debug build.

To sum, I can reproduce this issue on both Buri and Unagi. It can easily reproduce with debug build of V1.2 and V1.3. The repro frequency is about 50%. When I flashed unagi with debug build of V1.1(b2g18). The issue is quite hard to repo. Tried 20 times and had no luck to reproduce.

The result described in comment 29 reminds me that bug 906019 may change the behaviour of our stack a little bit. Originally, we got adapter properties with a blocking call, and then received PropertyChanged with correct adapter name after the blocking call is finished. At that time, an instance of adapter is created in content process, and the signal PropertyChanged is broadcasted to content process, too. So, the adapter name is updated successfully. After applying changes in bug 906019, the blocking call is replaced with a non-blocking call. The event PropertyChanged is received and broadcasted before the instance of adapter is created in content process. So we failed to update adapter name.

I reverted the changes in bug 906019, that is, getting the adapter properties with a blocking call, and the reproduce rate is decreased to 30%.

(In reply to Gina Yeh [:gyeh] [:ginayeh] from comment #31) > I reverted the changes in bug 906019, that is, getting the adapter > properties with a blocking call, and the reproduce rate is decreased to 30%. Hey :gyeh, just a quick follow up on where we are at this ? Is there a WIP patch here ? I am wondering if its a timing issue, could we add some delay mechanism in here if fixing this fully seems too hard ?

Hi bajaj, the patch is coming. After discussing with Eric and Marco, we came up a solution ;)

Discussed with Gina about this issue yesterday. She will send a patch soon.

Patch updated.

Comment on attachment 8334339 [details] [diff] [review] Patch 1(v2): Broadcast AdapterAdded after adapter name is updated Review of attachment 8334339 [details] [diff] [review]: ----------------------------------------------------------------- LGTM. Thanks.

Clear ni? since it's been closed.

I just found that the patch wasn't successfully pushed into branch v1.2, and comment 41 is an empty changeset. So, I'm going to re-open this bug and attach a patch for branch v1.2 later.

Ryan, could you help to push the patch to branch v1.2?

Seems like Ryan is on vacation. Tomcat, can you help?

Hi Gina, talked with Ed and he will take care of the checkin-needed bugs

I don't have this repo checked out at the moment, but will try to get to the checkin-neededs in general over the next few days :-)

For the sake of tracking, I'm close this but switch the 1.2 flag to affected to indicate this needs an uplift.

Yikes, don't know how that happened. Sorry :( https://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/8cc240005acc

Thank you all, guys.

Verified that the bluetooth device name does not disappear after reactivating it on 1.2 and 1.3 1.2 Environmental Variables: Device: Buri v1.2 COM RIL BuildID: 20131204004003 Gaia: 8d762f3376318fd6be390432db750ae4904c9ab6 Gecko: 758f3fb32dda Version: 26.0 Firmware Version: V1.2_20131115 1.3 Master Environmental Variables Device: Buri v1.3 COM RIL Build ID: 20131203040236 Gecko: 8648aa476eef Gaia: 31808a29cfcffa584b6a88b4f1e515387f485a1b Platform Version: 28.0a1 RIL Version: 01.02.00.019.102 Firmware Version: v1.2_20131115