Closed
Bug 1007576
Opened 11 years ago
Closed 10 years ago
[bluez] Update CoD value after device found while doing NFC pairing
Categories
(Firefox OS Graveyard :: Bluetooth, defect)
Tracking
(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)
People
(Reporter: ashiue, Assigned: shawnjohnjr)
References
Details
(Whiteboard: [p=8])
Attachments
(4 files, 2 obsolete files)
+++ This bug was initially created as a clone of Bug #970148 +++ Master branch (V1.4) code - 2014/2/7 Mako device Steps: 1. Launch "Settings" app 2. Enable "NFC" settings 3. Tap the phone with bluetooth earphone Expected result: The bluetooth turned on, and the earphone connected Actual result: Bluetooth turned on and NFC paired, but earphone is not connected +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Verified on Gaia 347d0517f0a77122c876d5f62c0942006a7a0bfe Gecko https://hg.mozilla.org/mozilla-central/rev/8be0e21fd300 BuildID 20140507160203 Version 32.0a1 NFC-capable bluetooth earphone(Sony MH10) still can't be paired often
Updated•11 years ago
|
blocking-b2g: --- → 2.0?
Updated•11 years ago
|
Whiteboard: [p=8][ETA:5/30]
Comment 2•11 years ago
|
||
Set target milestone to sprint3 per ETA proposed. 2.0+ for it's a bug which impacts key feature.
blocking-b2g: 2.0? → 2.0+
Target Milestone: --- → 2.0 S3 (6june)
Reporter | ||
Comment 3•10 years ago
|
||
This case no longer exist on build Gaia 101c500903a2477f9de1ea5ce523b9e0be4d45d0 Gecko https://hg.mozilla.org/mozilla-central/rev/41a54c8add09 BuildID 20140518040203 Version 32.0a1 It seems this bug been fixed by other fixing bug ...
Comment 4•10 years ago
|
||
(In reply to ashiue from comment #3) > This case no longer exist on build > Gaia 101c500903a2477f9de1ea5ce523b9e0be4d45d0 > Gecko https://hg.mozilla.org/mozilla-central/rev/41a54c8add09 > BuildID 20140518040203 > Version 32.0a1 > > It seems this bug been fixed by other fixing bug ... Should be bug 1003472. Let me check it out.
Comment 5•10 years ago
|
||
(In reply to Eric Chou [:ericchou] [:echou] from comment #4) > (In reply to ashiue from comment #3) > > This case no longer exist on build > > Gaia 101c500903a2477f9de1ea5ce523b9e0be4d45d0 > > Gecko https://hg.mozilla.org/mozilla-central/rev/41a54c8add09 > > BuildID 20140518040203 > > Version 32.0a1 > > > > It seems this bug been fixed by other fixing bug ... > > Should be bug 1003472. Let me check it out. Oh, wait, I may be wrong. I thought this is another issue. Hm ...
Reporter | ||
Updated•10 years ago
|
Summary: [NFC][Bluetooth] NFC-capable bluetooth earphone can't be paired often → [NFC][Bluetooth] Paired earphone does not show on "Paired devices" area when BT paired via NFC while BT off
Reporter | ||
Comment 6•10 years ago
|
||
Sorry I misunderstanding this problem. This is not a paired issue, it's an UI problem on setting page that paired earphone does not show on "Paired devices" area when BT paired via NFC while BT off. Steps: 1. Launch "Settings" app 2. Enable "NFC" settings 3. Go to Bluetooth in setting (Please stay at this page) 4. Tap the phone with bluetooth earphone Expected result: The bluetooth turned on, the earphone paired and connected, and the device show on "Paired devices" area Actual result: The bluetooth turned on, and the earphone paired and connected, but no device show on "Paired devices" area
Reporter | ||
Comment 7•10 years ago
|
||
Comment 8•10 years ago
|
||
I can reproduce (not always, about 20%) and just found the root cause -- Even if settings app calls getPairedDevices() after it received pairedstatuschanged, it may still not be able to get the device which was just paired. At the moment of event pairedstatuschanged being fired to gaia, event "propertychanged" of BluetoothAdapter property "devices" may not have been fired to child process. Therefore BluetoothAdapter.mDeviceAddresses may not be up-to-date if Gaia calls getPairedDevices immediately. I'll try to fix it.
Comment 9•10 years ago
|
||
After reviewing the user impact, this doesn't need to block.
blocking-b2g: 2.0+ → backlog
Updated•10 years ago
|
Target Milestone: 2.0 S3 (6june) → 2.0 S4 (20june)
Comment 10•10 years ago
|
||
(In reply to Wesley Huang [:wesley_huang] from comment #9) > After reviewing the user impact, this doesn't need to block. Not sure why the user impact is low if they can't see if the BT headset is connected in the list. If there are no major risks, this should be fixed in 2.0 as users will see the issue and may think the BT headset is not connected (potential customer service calls).
Comment 11•10 years ago
|
||
Not sure if related, but it's possible to pair a device with NFC, like a speaker (UE Mini Boom specifically), that seemingly has no exposed bluetooth functionality. The speaker doesn't have a headphone icon, and won't work as it's not connected. Clicking on the device can only unpair, but not connect. Switch on BT on the speaker, and pairs with a headphone icon (maybe needs more negotiation, rather than static pairing?) If not related, I'll open a bug to track.
Assignee | ||
Comment 12•10 years ago
|
||
(In reply to Garner Lee from comment #11) > Not sure if related, but it's possible to pair a device with NFC, like a > speaker (UE Mini Boom specifically), that seemingly has no exposed bluetooth > functionality. The speaker doesn't have a headphone icon, and won't work as > it's not connected. > > Clicking on the device can only unpair, but not connect. Switch on BT on the > speaker, and pairs with a headphone icon (maybe needs more negotiation, > rather than static pairing?) > > If not related, I'll open a bug to track. I'm working on bug 1015819, as it already marked as 2.0+.
Comment 14•10 years ago
|
||
Discussed this in triage and agree with comment #13
blocking-b2g: 2.0? → 2.0+
Updated•10 years ago
|
Target Milestone: 2.0 S4 (20june) → 2.0 S5 (4july)
Updated•10 years ago
|
Whiteboard: [p=8][ETA:5/30] → [p=8][ETA:7/4]
Assignee | ||
Updated•10 years ago
|
Assignee: echou → shuang
Assignee | ||
Comment 15•10 years ago
|
||
After the patch of bug 1015819 landed, I've tested MBH10 NFC bluetooth headset on Nexus 4, it works.
Assignee | ||
Updated•10 years ago
|
Summary: [NFC][Bluetooth] Paired earphone does not show on "Paired devices" area when BT paired via NFC while BT off → [bluez] Update CoD value after device found while doing NFC pairing
Assignee | ||
Comment 16•10 years ago
|
||
Although bug 1015819 patch landed, if there is a device-found event raises, CoD value will be updated again with incorrect value. It's similar to replace 'Icon', we need to handle them at both places.
Assignee | ||
Comment 17•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Attachment #8446394 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8446399 -
Attachment description: bug1007576.patch → Bug 1007576 - [bluez] Update CoD value after device found while doing NFC pairing
Assignee | ||
Comment 19•10 years ago
|
||
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #18) > Created attachment 8446399 [details] [diff] [review] > Bug 1007576 - [bluez] Update CoD value after device found while doing NFC > pairing This is for Flame device which uses bluez backend.
Comment 21•10 years ago
|
||
Comment on attachment 8446399 [details] [diff] [review] Bug 1007576 - [bluez] Update CoD value after device found while doing NFC pairing Review of attachment 8446399 [details] [diff] [review]: ----------------------------------------------------------------- r=me with nit addressed. ::: dom/bluetooth/bluez/BluetoothDBusService.cpp @@ +1792,5 @@ > + // Check whether the properties array contains CoD. If it doesn't, fallback to restore > + // CoD value. This usually happens due to NFC directly triggers pairing that > + // makes bluez not update CoD value. > + if (FindProperty(properties, "Class") < 0) { > + uint32_t cod = 0; Please move this declaration into the if-block below since |cod| is only used in there.
Attachment #8446399 -
Flags: review?(echou) → review+
Assignee | ||
Updated•10 years ago
|
Attachment #8446399 -
Attachment is obsolete: true
Assignee | ||
Comment 22•10 years ago
|
||
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 23•10 years ago
|
||
https://hg.mozilla.org/integration/b2g-inbound/rev/a8eaedc48ebc
Keywords: checkin-needed
Comment 24•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/a8eaedc48ebc
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment 25•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/da6103e874b6
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
status-firefox31:
--- → wontfix
status-firefox32:
--- → fixed
status-firefox33:
--- → fixed
Whiteboard: [p=8][ETA:7/4] → [p=8]
Comment 26•10 years ago
|
||
According to comment 6, this issue has been verified successfully on Flame v2.0 & v2.1 See attachment: verify_video.MP4 Reproducing rate: 0/5 Flame 2.0 versions: Gaia-Rev 8d1e868864c8a8f1e037685f0656d1da70d08c06 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g32_v2_0/rev/c756bd8bf3c3 Build-ID 20141202000201 Version 32.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.034707 FW-Date Tue Dec 2 03:47:18 EST 2014 Bootloader L1TC00011880 Flame 2.1 versions: Gaia-Rev ccb49abe412c978a4045f0c75abff534372716c4 Gecko-Rev https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/18fb67530b22 Build-ID 20141202001201 Version 34.0 Device-Name flame FW-Release 4.4.2 FW-Incremental eng.cltbld.20141202.034824 FW-Date Tue Dec 2 03:48:34 EST 2014 Bootloader L1TC00011880
You need to log in
before you can comment on or make changes to this bug.
Description
•