818392 - Bluetooth pairing dialog doesn't display any message (or a pairing PIN), the first time you try to pair after (re)booting -- just cancel/pair buttons

Status: RESOLVED WORKSFORME

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

Description

[Daniel Holbert [:dholbert]]

Attachment: screenshot of blank pairing dialog

STR:
 1. Reboot phone. (or boot it up, from being off)  <---- important
 2. Enable bluetooth, if it's not already enabled. (I've reproduced this with it already-enabled before I reboot, and enabling it after I boot up.)
 3. Try to pair with a device. (You can initiate this from the B2G phone or from the other device; doesn't matter)

EXPECTED RESULTS: Useful pairing prompt on B2G phone

ACTUAL RESULTS: Blank pairing prompt on B2G phone, with 2 horizontal lines, and no text -- just [Cancel][Pair] buttons at the bottom.

NOTE: At this point, if I hit "cancel" and repeat the process, it works as expected.  I can *only* reproduce this the first time I try to pair, after I reboot/power on the phone.  However, this covers a significant number of real-world pairing events, since pairing is such an infrequent thing. (it's likely that you'll only need to do it at most once per phone-boot-cycle, and it sucks if that one time is broken)



Quoting cjones from similar bug 804248 comment 4 (similar in that the pairing PIN isn't displayed there either):
> This is an extremely important security measure.  I wouldn't a ship a phone
> with this bug.

Hence, requesting blocking-basecamp.

Comment 1

[Daniel Holbert [:dholbert]]

Build ID: 20121203114956

I tested this using both my Android phone and my thinkpad (running Ubuntu) as the other device, and reproduced it with both.

Comment 2

[Daniel Holbert [:dholbert]]

Pretty sure this is a regression, too.  Back when I filed bug 804248, we displayed at least _some_ message on the first bluetooth pairing session.

Comment 3

[Alex Keybl [:akeybl]]

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

Comment 4

[Dietrich Ayala (:dietrich)]

Pretty sure this was fixed last week. Evelyn, can you check if this is a dupe?

Comment 5

[Daniel Holbert [:dholbert]]

Yup, this is WFM on the new beta build (20121206062128).

Resolving WFM. (Feel free to update that to Resolved|Dupe if you find the bug that fixed this)