Closed Bug 1056413 Opened 10 years ago Closed 10 years ago

[KK][Bluetooth] Pairing devices after cancelling results in unresponsive page

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:2.0+, firefox32 wontfix, firefox33 wontfix, firefox34 fixed, b2g-v2.0 verified, b2g-v2.1 verified)

VERIFIED FIXED
2.1 S3 (29aug)
blocking-b2g 2.0+
Tracking Status
firefox32 --- wontfix
firefox33 --- wontfix
firefox34 --- fixed
b2g-v2.0 --- verified
b2g-v2.1 --- verified

People

(Reporter: smiko, Assigned: jaliu)

Details

(Keywords: regression, Whiteboard: [2.0-exploratory-kk] [p=2])

Attachments

(4 files, 5 obsolete files)

79.56 KB, text/plain
Details
11.95 KB, text/plain
Details
4.74 KB, patch
Details | Diff | Splinter Review
3.69 KB, patch
Details | Diff | Splinter Review
Attached file RecievingDevice.txt
Description:
Pairing a device via bluetooth after cancelling out of the Bluetooth Request screen results in a non responsive screen on the device receiving the request.

Repro Steps:
1) Install the 165 base
2) Update a Flame to 20140820030000 KK build
3) Open Settings > Bluetooth > and select a second device to pair to
4) On the Bluetooth Request page select "Cancel"
5) Select the same device from the list

Actual:
On the device receiving the request, a blank screen with two buttons is displayed. 
The buttons Pair and Cancel do not function. 
When tapping the Home button, The Cancel and Pair buttons are displayed on the Notification Bar.

Expected:
On the device receiving the request, the Bluetooth Request page goes away once the other device cancels out of pairing.
Then the devices can restart the process

Flame 2.0 KK (319mb)

Environmental Variables:
Device: Flame 2.0 (319mb)
Build ID: 20140820030000
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0)
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Keywords: bluetooth, pair, Kit Kat, KK, 

Notes:
1) The only way to recover the Notifications Bar and pair the phones is to restart the device.
2) Possibly related to Bug 911611

Repro frequency: 100%

See attached: logcats

Video clip: http://youtu.be/567m6hMTaWA
Attached file SendingDevice.txt
This issue DOES repro on Flame 2.0(512mb) KK 156 base

Actual Result: 
On the device receiving the request, a blank screen with two buttons is displayed. 
The buttons Pair and Cancel do not function. 
When tapping the Home button, The Cancel and Pair buttons are displayed on the Notification Bar.

Flame 2.0 KK (512mb)

Environmental Variables:
Device: Flame 2.0 (512mb)
Build ID: 20140820030000
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0)
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

This issue does NOT repro on Flame 2.1 (319mb) 123 base, Flame 2.0 (319mb) 123 base, or Open C 2.0 123 base

Flame 2.1 (319mb)

Environmental Variables:
Device: Flame Master (319mb)
BuildID: 20140820040203193
Gaia: df39c463259d348396ef7f143c2c780eeb8f02d8
Gecko: ffdd1a398105
Version: 34.0a1 (Master) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0 (319mb)

Environmental Variables:
Device: Flame 2.0 (319mb)
BuildID: 20140820000201
Gaia: 88db39a0826086024631049d83ae6aa397f0918d
Gecko: 2092ac87eceb
Version: 32.0 (2.0) 
Firmware Version: v123
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

Open C 2.0

Environmental Variables:
Device: Open_C 2.0
BuildID: 20140820000201
Gaia: 88db39a0826086024631049d83ae6aa397f0918d
Gecko: 2092ac87eceb
Version: 32.0 (2.0) 
Firmware Version: P821A10V1.0.0B06_LOG_DL
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
Whiteboard: [2.0-exploratory-kk]
Please fix your title.
Flags: needinfo?(ktucker) → needinfo?(smiko)
Flags: needinfo?(smiko) → needinfo?(ktucker)
Summary: [B2G][2.0]{Flame KK] Pairing devices after cancelling results in unresponsive page → [KK][Bluetooth] Pairing devices after cancelling results in unresponsive page
[Blocking Requested - why for this release]:

Since this issue causes non functional buttons and causes the bottom half of the bluetooth confirmation screen to appear on the status bar when the user goes home I'm nominating 2.0?
blocking-b2g: --- → 2.0?
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
QA Wanted - Does this reproduce on a the kitkat base image?
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
This issue does not occur on the v165 KitKat base image (both devices).

Cancelling the pair request on Device A dismisses the pair request on Device B and trying again does not lead to an unresponsive state on Device B.
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
Keywords: qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage?+]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?+] → [QAnalyst-Triage+]
QA Whiteboard: [QAnalyst-Triage+]
NI, Eric Chou to get started here.
blocking-b2g: 2.0? → 2.0+
Flags: needinfo?(echou)
QA Contact: jmercado
This issue occurs on the earliest build we have access to for Flame 2.0 on the 165 KitKat Base.

Environmental Variables:
Device: Flame 2.0
BuildID: 20140815143240
Gaia: d889984833025f208cfd3f3c2c37c87940a529dc
Gecko: 6329352ca531b977979451e77e5862af485388b2
Version: 32.0 (2.0) 
Firmware Version: 
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(jmitchell)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(jmitchell)
Does this reproduce on 1.4 with the kitkat base?
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
(In reply to Jason Smith [:jsmith] from comment #9)
> Does this reproduce on 1.4 with the kitkat base?

Jason - this is not something we can test: we do not have any 1.4 kitkat builds, only a few 2.0 builds.

If you are asking about 'just the kitkat base'; that was addressed in comment 6
QA Whiteboard: [QAnalyst-Triage+]
Keywords: qawanted
(In reply to bhavana bajaj [:bajaj] from comment #7)
> NI, Eric Chou to get started here.

Assigned to Jamin.
Assignee: nobody → jaliu
Flags: needinfo?(echou)
Status: NEW → ASSIGNED
Whiteboard: [2.0-exploratory-kk] → [2.0-exploratory-kk] [p=2]
Comment on attachment 8480421 [details] [diff] [review]
(for 2.0) Broadcast system message to notify Gaia when Bluetooth authentication failure occurs. (v1)

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

::: dom/bluetooth/bluedroid/BluetoothServiceBluedroid.cpp
@@ +756,5 @@
> +      NS_DispatchToMainThread(
> +        new BondStateChangedCallbackTask(remoteBdAddress, bonded));
> +      break;
> +    }
> +    case BT_STATUS_AUTH_FAILURE:

I think we should add BT_STATUS_BUSY.
Attachment #8480421 - Flags: review?(shuang) → review+
Comment on attachment 8480422 [details] [diff] [review]
(for master) Broadcast system message to notify Gaia when Bluetooth authentication failure occurs. (v1)

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

::: dom/bluetooth/BluetoothCommon.h
@@ +143,5 @@
>    STATUS_PARM_INVALID,
>    STATUS_UNHANDLED,
>    STATUS_AUTH_FAILURE,
> +  STATUS_RMT_DEV_DOWN,
> +  STATUS_AUTH_REJECTED

This is CAF specific change. AOSP does nont have STATUS_AUTH_REJECTED.
Attachment #8480422 - Flags: review?(shuang) → review-
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #16)
> Comment on attachment 8480422 [details] [diff] [review]
> (for master) Broadcast system message to notify Gaia when Bluetooth
> authentication failure occurs. (v1)
> 
> Review of attachment 8480422 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/bluetooth/BluetoothCommon.h
> @@ +143,5 @@
> >    STATUS_PARM_INVALID,
> >    STATUS_UNHANDLED,
> >    STATUS_AUTH_FAILURE,
> > +  STATUS_RMT_DEV_DOWN,
> > +  STATUS_AUTH_REJECTED
> 
> This is CAF specific change. AOSP does nont have STATUS_AUTH_REJECTED.

Let's ignore STATUS_AUTH_REJECTED... Until someday we can really add CAF flag to resolve this kind of HAL pollution problem.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #16)
> Comment on attachment 8480422 [details] [diff] [review]
> (for master) Broadcast system message to notify Gaia when Bluetooth
> authentication failure occurs. (v1)
> 
> Review of attachment 8480422 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: dom/bluetooth/BluetoothCommon.h
> @@ +143,5 @@
> >    STATUS_PARM_INVALID,
> >    STATUS_UNHANDLED,
> >    STATUS_AUTH_FAILURE,
> > +  STATUS_RMT_DEV_DOWN,
> > +  STATUS_AUTH_REJECTED
> 
> This is CAF specific change. AOSP does nont have STATUS_AUTH_REJECTED.

Thank you for the reminding.
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #15)
> I think we should add BT_STATUS_BUSY.
Thank you.
I've added it to #attachment 8480478 [details] [diff] [review] and #attachment 8480480 [details] [diff] [review].
Comment on attachment 8480480 [details] [diff] [review]
(for master) Broadcast system message to notify Gaia when Bluetooth authentication failure occurs. (v2)

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

Note this is for v2.0 only
Attachment #8480480 - Flags: review?(shuang) → review+
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #22)
> Comment on attachment 8480480 [details] [diff] [review]
> (for master) Broadcast system message to notify Gaia when Bluetooth
> authentication failure occurs. (v2)
> 
> Review of attachment 8480480 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Note this is for v2.0 only

Sorry I'm writing non-sense here. This is for master :(
Comment on attachment 8480478 [details] [diff] [review]
(for 2.0) Broadcast system message to notify Gaia when Bluetooth authentication failure occurs. (v2)

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

LGTM
Attachment #8480478 - Flags: review?(shuang) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/61eeef436985
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 2.1 S3 (29aug)
This issue is verified fixed on Flame 2.1 and 2.0.

Result: On the device receiving the request, the confirmation dialog disappears immediately after the other device cancelled the pairing.

Flame 2.1

Device: Flame 2.1 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141027001201
Gaia: c97463d61f45513a2123b19610386ddbfc916819
Gecko: 4f8c0c021128
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 34.0 (2.1)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Flame 2.0

Device: Flame 2.0 (319mb)(Kitkat Base)(Full Flash)
BuildID: 20141027000202 
Gaia: 2183b4f3ec0eb47ab1f133c31732ec53b08ad253
Gecko: 43bee45176c4
Gonk: 6e51d9216901d39d192d9e6dd86a5e15b0641a89
Version: 32.0 (2.0)
Firmware: V188
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
Status: RESOLVED → VERIFIED
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: