Created attachment 8433073 [details] BT-20140603_14_06.rar * Description: There is no respond when tap the device, after the device cancel to pair with test device. Detail info, please check video in attachment. * Reproduction steps: 1. Go to "Settings", go to "Bluetooth" subsection, and turn on bluetooth 2. Tap on "Visible to all" 3. Another Device(A device) turn on BT and find test device 4. Tap test device on A device to pair 5. Tap the "Pair" on test device, tap "Cancel" on A device 6. Tap A device on test device to pair. * Expected result: The comfirm notification page open. * Actual result: There is no respond when tap A device on test device to pair. Occurrence time：about 14:06 * Reproduction build:(Buri - Firefox OS V1.4 inside) - Gaia 17b102ee8d9a724b62285547cc5f1c5d30bfb01c - Gecko https://hg.mozilla.org/releases/mozilla-b2g30_v1_4/rev/95be84248033 - BuildID 20140520000201 - Version 30.0 * Reproduction Frequency - 100%
I can reproduce this bug follow the steps. hcidump shows that we did received Authentication Failure from device A. Will start to find out what's the root cause.
Status: UNCONFIRMED → NEW
Ever confirmed: true
When user try to pair with other device after the canceled pairing, pairingAddress maintained in gaia is not cleared. Hence it will return directly at https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/settings/js/bluetooth.js#L608 In current code base, this address will be cleared if bluetooth-cancel or onpairedstatuschanged is received by gaia, but none of these is happened.
This bug can be reproduced on 1.2, 1.3, too. 2.0 and m-c will not encounter this since gaia won't set the pairingAddress for passive paring request.
A solution I can think of right now is * Gecko reports an ondeviceremoved event to gaia with the removed device address (might restrict that only fired this event when we're in passive paring process if neccessary) * Gaia uses defaultAdapter.ondeviceremoved to clear pairingAddress However, I am not sure is it suitable to make this change for old code base only. Ian, do you have any thoughts on this from Gaia side?
As offline discussion and mentioned on comment 2, we use flag 'pairingAddress' to make sure only one pairing procedure. In case of this reproduced steps, a user confirmed the pairing request in passive mode, it means that the pairing process is running already(https://github.com/mozilla-b2g/gaia/blob/v1.4/apps/settings/js/bluetooth.js#L889-L900)(passive mode, not user cancel). But other device is able to cancel the fired pairing request after we have confirmed. Somehow, Gaia will expect some event to clear up the status in this failed case. Since there is no way to reach the response, I would like to use 'ondeviceremoved' event as Jocelyn's proposal. But the naming might be more clearly for figuring out the symptom.
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 2 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.