Closed Bug 1175955 Opened 9 years ago Closed 9 years ago

passive pairing not work when fresh flash

Categories

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
critical

Tracking

(blocking-b2g:2.5+, b2g-v2.2 unaffected, b2g-master fixed)

VERIFIED FIXED
FxOS-S5 (21Aug)
blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- unaffected
b2g-master --- fixed

People

(Reporter: nhirata, Assigned: gasolin)

References

Details

(Keywords: crash, regression, smoketest, Whiteboard: [spark], [b2g-crash])

Crash Data

Attachments

(3 files)

This bug was filed from the Socorro interface and is 
report bp-d4b3195b-4a9b-4294-9483-a26d02150618.
=============================================================
Crashing Thread
Frame 	Module 	Signature 	Source
0 	libxul.so 	mozilla::dom::bluetooth::BluetoothAdapter::IsBluetoothCertifiedApp() 	/home/worker/workspace/B2G/objdir-gecko/dist/include/nsCOMPtr.h:693
1 	libxul.so 	mozilla::dom::bluetooth::BluetoothAdapter::BluetoothAdapter(nsPIDOMWindow*, mozilla::dom::bluetooth::BluetoothValue const&) 	/home/worker/workspace/gecko/dom/bluetooth/bluetooth2/BluetoothAdapter.cpp:321
2 	libxul.so 	mozilla::dom::bluetooth::BluetoothAdapter::Create(nsPIDOMWindow*, mozilla::dom::bluetooth::BluetoothValue const&) 	/home/worker/workspace/gecko/dom/bluetooth/bluetooth2/BluetoothAdapter.cpp:449
3 	libxul.so 	mozilla::dom::bluetooth::BluetoothManager::AppendAdapter(mozilla::dom::bluetooth::BluetoothValue const&) 	/home/worker/workspace/gecko/dom/bluetooth/bluetooth2/BluetoothManager.cpp:156
4 	libxul.so 	GetAdaptersTask::ParseSuccessfulReply(JS::MutableHandle<JS::Value>) 	/home/worker/workspace/gecko/dom/bluetooth/bluetooth2/BluetoothManager.cpp:92
5 	libxul.so 	mozilla::dom::bluetooth::BluetoothReplyRunnable::Run() 	/home/worker/workspace/gecko/dom/bluetooth/bluetooth2/BluetoothReplyRunnable.cpp:109
6 	libxul.so 	nsThread::ProcessNextEvent(bool, bool*) 	/home/worker/workspace/gecko/xpcom/threads/nsThread.cpp:848
7 	libxul.so 	NS_ProcessNextEvent(nsIThread*, bool) 	/home/worker/workspace/gecko/xpcom/glue/nsThreadUtils.cpp:265
8 	libxul.so 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	/home/worker/workspace/gecko/ipc/glue/MessagePump.cpp:95
9 	libxul.so 	MessageLoop::RunInternal() 	/home/worker/workspace/gecko/ipc/chromium/src/base/message_loop.cc:234
10 	libxul.so 	MessageLoop::Run() 	/home/worker/workspace/gecko/ipc/chromium/src/base/message_loop.cc:227
11 	libxul.so 	nsBaseAppShell::Run() 	/home/worker/workspace/gecko/widget/nsBaseAppShell.cpp:165
12 	libxul.so 	XRE_RunAppShell 	/home/worker/workspace/gecko/toolkit/xre/nsEmbedFunctions.cpp:778
13 	libxul.so 	MessageLoop::RunInternal() 	/home/worker/workspace/gecko/ipc/chromium/src/base/message_loop.cc:234
14 	libxul.so 	MessageLoop::Run() 	/home/worker/workspace/gecko/ipc/chromium/src/base/message_loop.cc:227
15 	libxul.so 	XRE_InitChildProcess 	/home/worker/workspace/gecko/toolkit/xre/nsEmbedFunctions.cpp:614
16 	libxul.so 	content_process_main(int, char**) 	/home/worker/workspace/gecko/ipc/contentproc/plugin-container.cpp:236
17 	libxul.so 	mozilla::ipc::ProcLoaderLoadRunner::DoWork() 	/home/worker/workspace/gecko/ipc/glue/ProcessUtils_linux.cpp:435
18 	libxul.so 	XRE_ProcLoaderServiceRun 	/home/worker/workspace/gecko/ipc/glue/ProcessUtils_linux.cpp:594
19 	b2g 	main 	/home/worker/workspace/gecko/b2g/app/B2GLoader.cpp:219
20 	libc.so 	__libc_init 	/home/worker/workspace/B2G/bionic/libc/bionic/libc_init_dynamic.cpp:112
21 	b2g 	b2g@0xc1da 	
22 	linker 	set_soinfo_pool_protection 	/builds/slave/b2g_m-cen_flm-kk_eng_ntly-0000/build/bionic/linker/linker.cpp:291
23 		@0xbed4da6a

STR:
1. turn on bluetooth/bluetooth visibility
2. using mac try to connect to device via bluetooth
3. let bluetooth connection expire
4. select notification for blue tooth
5. tap on overlay

expected: no crash after the bluetooth expiration overlay
Actual: crash on the overlay

Note:
Build ID               20150618064850
Gaia Revision          ac61ff69e03db3d4ca752d6b4a29c93633127b8d
Gaia Date              2015-06-18 05:08:23
Gecko Revision         b018f8e192cb1116442370f81b0832362b8124df
Gecko Version          41.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150618.063502
Firmware Date          Thu Jun 18 06:35:11 UTC 2015
Bootloader             s1
Whiteboard: [spark]
Keywords: qaurgent, qawanted
Whiteboard: [spark] → [spark], [b2g-crash]
QAWanted: to see if there may be different steps to reproduce this issue.
I couldn't repro yet after running into it once.
Switching the tag for steps-wanted so it more accurately represents what work we'll be doing.  Attempting this now.
Keywords: qawantedsteps-wanted
This bug is similar bug 1154852.  I reproduced the crash once but I was able to get the pairing request notification instead of the pairing screen on a fresh flash 3/3 times.  Will do branch checks in the morning and try to find more consistent steps for the crash.

Environmental Variables:
Device: Aries 3.0
BuildID: 20150618064850
Gaia: ac61ff69e03db3d4ca752d6b4a29c93633127b8d
Gecko: b018f8e192cb1116442370f81b0832362b8124df
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 41.0a1 (3.0) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
See Also: → 1154852
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(ktucker)
This issue DOES occur on Flame 3.0 builds.

Actual Results: The user recieves bluetooth notifications after a fresh flash until either Bluetooth crash or the phone is restarted.  I was unable to get the Flame to crash but I do believe that it is related.

Environmental Variables:
Device: Flame 3.0
BuildID: 20150619010205
Gaia: a0df9c367a68764bdcf2e2e1c4d27f0d6ee165b8
Gecko: 2694ff2ace6a
Gonk: a4f6f31d1fe213ac935ca8ede7d05e47324101a4
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0


This issue does NOT occur on Flame 2.2 builds.

Actual Results: The user is shown the Bluetooth pairing screen on a fresh flesh.

Environmental Variables:
Device: Flame 2.2
BuildID: 20150619002501
Gaia: 1c33072e33c279c8aa5cb5e4a3e4da6af6cd818b
Gecko: 5ad34a170633
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0
Flags: needinfo?(ktucker)
Keywords: qawantedregression
Flags: needinfo?(ktucker)
[Blocking Requested - why for this release]:

Nominating this 3.0? since bluetooth does not work until the device is reset.
blocking-b2g: --- → 3.0?
QA Contact: jmercado
Bug 1094759 seems to have caused this issue. Naoki who should this go to now?

B2g-inbound Regression Window

Last Working 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150604012244
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 64ce149fabf1
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

First Broken 
Environmental Variables:
Device: Flame 3.0
BuildID: 20150604020845
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 4f7e7631e277
Version: 41.0a1 (3.0) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Last Working gaia / First Broken gecko - Issue does NOT occur
Gaia: e0fbadeb78a96137f071d9be7a47ef9fe882d17f
Gecko: 4f7e7631e277

First Broken gaia / Last Working gecko - Issue DOES occur
Gaia: c1ef854924f18357832ddcf98dc6c42391d5599e
Gecko: 64ce149fabf1

Gaia Pushlog: https://github.com/mozilla-b2g/gaia/compare/e0fbadeb78a96137f071d9be7a47ef9fe882d17f...c1ef854924f18357832ddcf98dc6c42391d5599e
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(nhirata.bugzilla)
Jocelyn, it only occurs after a fresh flash.  Possibly an initialization issue?  Could you have one of the devs check please?
Flags: needinfo?(joliu)
A quick summary of Jayme's test result,

1) After a fresh flash, we will only get the pairing request in notification tray instead of seeing the pairing screen. The pairing screen will show up after restart the phone (bluetooth crash will also cause the phone to restart, so I think that's the only way here based on Jayme's comment.)

2) When 1) happens, sometimes we will hit bluetooth crash, sometimes we can click the notification tray to complete pairing without crash.

Based on Jayme's regression window, 1) is caused by the gaia patch.
IMO, we will need gaia developers' help to check on why the pairing screen won't show after a fresh flash (1) first.
ni gaia developers here to get some assistance from them.

Jayme, please correct me if I misunderstood your comments, thanks.
Flags: needinfo?(joliu)
Flags: needinfo?(iliu)
Flags: needinfo?(gasolin)
Hi Jayme,

Set ni just in case you didn't see Comment 9.
Feel free to clear the ni if I understand your comments correctly.

Thanks,
Jocelyn
Flags: needinfo?(jmercado)
Hi Jocelyn

For (1) the bluetooth crash does not always restart the phone, but Bluetooth restarts afterwards so the issue no longer occurs.

For (2) I've not been able to pair the device at all until either Bluetooth crashes and restarts, or the entire phone restarts.  As long as the notification is occurring instead of the pairing screen the user cannot pair.  Pressing the notification does not bring the pairing screen up.
Flags: needinfo?(jmercado) → needinfo?(joliu)
Hi Jayme,

Thanks for the clarification.

For 1), looks like the way to resolve this issue is by disabling and enabling bluetooth again.
(restart the phone will also do this.)

For 2), we're not able to pair unless we restart bluetooth based on Jayme's comment.

From gecko point of view, we just fires the pairing event to bluetooth app.
Maybe gaia developers could have some ideas that why the screen won't show up after a fresh flash.

(In reply to Jayme Mercado [:JMercado] from comment #11)
> Hi Jocelyn
> 
> For (1) the bluetooth crash does not always restart the phone, but Bluetooth
> restarts afterwards so the issue no longer occurs.
> 
> For (2) I've not been able to pair the device at all until either Bluetooth
> crashes and restarts, or the entire phone restarts.  As long as the
> notification is occurring instead of the pairing screen the user cannot
> pair.  Pressing the notification does not bring the pairing screen up.
Flags: needinfo?(joliu)
Upgrading to Smoketest Blocker
Keywords: smoketest
I full flashed latest m-c to my flame-kk and was able to reproduce the problem.
Pairing requests will only show in the notification tray, and no pairing screens will be shown to the user to proceed the pairing process.
I try to disable and enable BT again, the problem still exists.
Pairing screens can be shown only after restarting the phone.

Based on comment 7, Bug 1094759 might have caused this issue.
Tim, could you help to take a look at it?

Thanks,
Jocelyn
Flags: needinfo?(timdream)
(In reply to Jocelyn Liu [:jocelyn] [:joliu] from comment #15)
> Based on comment 7, Bug 1094759 might have caused this issue.
> Tim, could you help to take a look at it?

Hi Jocelyn, thanks for the needinfo. It's unfortunate that a difference start-up sequence of System app could result a crash, but I would recommend we fix the crash in the platform.

Based on the STR in bug 1179305 it's entirely possible System app have failed to start bluetooth functions correctly too.

Anyhow, Fred and Ian should be able to help to investigate on this.
Flags: needinfo?(timdream)
(In reply to Jocelyn Liu [:jocelyn] [:joliu] from comment #15)
> I full flashed latest m-c to my flame-kk and was able to reproduce the
> problem.
> Pairing requests will only show in the notification tray, and no pairing
> screens will be shown to the user to proceed the pairing process.
> I try to disable and enable BT again, the problem still exists.
> Pairing screens can be shown only after restarting the phone.
> 
> Based on comment 7, Bug 1094759 might have caused this issue.
> Tim, could you help to take a look at it?
> 
> Thanks,
> Jocelyn

BTW, I didn't reproduce the crash, but only reproduce that pairing screens are not shown.
(In reply to Jocelyn Liu [:jocelyn] [:joliu] from comment #17)
> BTW, I didn't reproduce the crash, but only reproduce that pairing screens
> are not shown.

We should not dup the two bug then? Why are we duping them?
Can not reproduce on 7/02 pvt flame-kk engineer build. 

Set `Settings > Bluetooth` on and set `Visible to all` on,
paring from Mac and wait for timeout, 
the dialog on device appeared and closed correctly without issue.
Flags: needinfo?(gasolin)
Work with jocelyn and spot the BT pairing dialog not pop up issue. 
After press home button twice to close and bring the screen on, the BT pairing dialog shows again.
(In reply to Fred Lin [:gasolin] from comment #20)
> Work with jocelyn and spot the BT pairing dialog not pop up issue. 
> After press home button twice to close and bring the screen on, the BT
> pairing dialog shows again.

I pressed the power button instead of the home button. :)
Sorry I miss typed power button as home button.


Another test with flash gaia via `make reset-gaia` also can't reproduce the issue.
More phenomenon,

When pairing screen is not shown, the notification in status bar shows 'Bluetooth pairing request' with request device's name.

When pairing screen is shown, the notification in status bar shows `Bluetooth` with blue bluetooth icon.
The difference is causing by `handlePairingRequest` method, it judges which method should be triggered by checking 'lockscreen.locked' value

https://github.com/mozilla-b2g/gaia/blob/master/apps/bluetooth/js/modules/pair_manager.js#L255

I suspect the issue is caused by the default 'lockscreen.locked' value is `true` with a fresh flash. 
So after press power button twice to close and bring the screen on (and unlock), the BT pairing dialog shows again.

I'll PTO afternoon, Naoki could you help check if the passive pairing is workable when fresh flash and make settings > lockscreen disabled?

also ni Greg for 'lockscreen.locked' value.
Flags: needinfo?(gweng)
Summary: crash in mozilla::dom::bluetooth::BluetoothAdapter::IsBluetoothCertifiedApp() → passive pairing not work when fresh flash
We can have an offline discussion at Monday maybe.
Flags: needinfo?(gweng)
per offline discussion with greg, greg will solve the settings key issue in his lockscreen patch.

greg, please help set depends field to your bug number so we could verify once the patch is landed.
Flags: needinfo?(gweng)
Thanks for Fred's investigation. Per comment 24, 26 and offline discussion with Fred, I sincerely recommend that we fix the 'lockscreen.locked' key to correctly respond for the state of lock screen. Greg, we need your help here. Thanks.
Flags: needinfo?(iliu)
I shall solve it at bug 1173284.
Flags: needinfo?(gweng)
Revise component to Gaia::System::Lockscreen per comment 26 & 28.
Component: Bluetooth → Gaia::System::Lockscreen
Flags: needinfo?(nhirata.bugzilla)
ni? Greg for the latest progress.

Greg, any update on this bug or bug 1173284 (I have no permission to access it)? Will you fix this bug or someone else?
Flags: needinfo?(gweng)
Yes. I now set it as review and need to fix some issue about that, and will attach the fix for this bug.
Flags: needinfo?(gweng)
Sorry Ben: since the patch became more complicated, so I now decide to patch this individually. And I will land the patch for this bug.
Assignee: nobody → gweng
As offline discussion with greg, we have test this issue again with nightly gecko/gaia and it works fine now.

@teri could you help confirm it?
Flags: needinfo?(twen)
Adding qawanted to see if this still reproduces.
Keywords: qaurgent, qawanted
Verified fixed against latest flame-kk and aries, but found different behaviors. 

Flame
 - pair request appeared in notification bar

Aries
 - pair request appeared on screen, if pressed homescreen button, request failed


**Aries
Gaia-Rev        dbacf8364f4505d021b7d8fb9cabea325004dbcc
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/abc56d57f6e1
Build-ID        20150803195455
Version         42.0a1
Device-Name     aries
FW-Release      4.4.2
FW-Incremental  eng.worker.20150803.191800
FW-Date         Mon Aug  3 19:18:08 UTC 2015
Bootloader      s1

**Flame
Gaia-Rev        dbacf8364f4505d021b7d8fb9cabea325004dbcc
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/abc56d57f6e1
Build-ID        20150803200436
Version         42.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.worker.20150803.192644
FW-Date         Mon Aug  3 19:26:53 UTC 2015
Bootloader      L1TC000118D0

ni Fred to confirm expected behaviors.
Flags: needinfo?(twen)
Flags: needinfo?(gasolin)
This issue still occurs exactly as described in commment 5.  If the user has not restarted their phone, they will receiving a notification that does nothing instead of a pairing screen.  

This occurs on both the latest Aries and Flame builds.

Environmental Variables:
Device: Aries 2.5
BuildID: 20150803134730
Gaia: 8dba2077f5e7137253fbb3faf10cd0b5f7da25c2
Gecko: 1d4f44ee5166
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 42.0a1 (2.5) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0

Environmental Variables:
Device: Flame 2.5
BuildID: 20150804030213
Gaia: caba8b26c52d3c771e9ea6fe288acdaf74c7707e
Gecko: 5b54831761b1
Gonk: 41d3e221039d1c4486fc13ff26793a7a39226423
Version: 42.0a1 (2.5) 
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:42.0) Gecko/42.0 Firefox/42.0
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage?]
Flags: needinfo?(pbylenga)
Flags: needinfo?(ktucker)
Keywords: qaurgent, qawanted
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Flags: needinfo?(pbylenga)
@greg as test result the issue is still remain.

If you can see pair request appeared in notification bar in non-lockscreen view, it means 'lockscreen.locked' value is not correct when fresh flashed.
Flags: needinfo?(gasolin) → needinfo?(gweng)
(In reply to Fred Lin [:gasolin] from comment #37)
> @greg as test result the issue is still remain.
> 
> If you can see pair request appeared in notification bar in non-lockscreen
> view, it means 'lockscreen.locked' value is not correct when fresh flashed.

1. from WebIDE I saw the value is correct, so I won't say that only according to UI changes
2. but this means we need deeper diagnosis of the bug; either

a). the value is still incorrect
b). the value is correct but there are some other causes

I'll deal with this after Bug 1189641. This doesn't mean this bug is less important, but the bug is ongoing so I hope to finish it first.
Flags: needinfo?(gweng)
Fred: I'm pretty sure the value is |false| after |DEVICE_DEBUG=1 make reset-gaia|, if you mean that. And after FTU and launching Settings app to set the value, it will correspond the user toggle faithfully. This remains true even after I reboot the device and toggle it again. So could you please check your assumption again? Or I misunderstood what you figured out?
Flags: needinfo?(gasolin)
Blocks: 1174840
It is a regression bug and causes crash.
blocking-b2g: 2.5? → 2.5+
Attached file logcat_1945.txt.txt
I can reproduce this issue on latest build of Aries kk v2.5.
Step:
1. Reset or flash device.
2. Turn on bluetooth/bluetooth visibility.
3. Using mac try to connect to device via bluetooth.
4. Drop down notification bar and tap notifacation.
5. Let bluetooth connection expire.
6. Lock screen.
7. Unlock screen.
8. Drop down notification bar and tap notifacation.
9. Tap "OK"

Result: crash on the overlay.
Reproduce rate:18/20
See attchment:Aries_v2.5.3gp & logcat_1945.txt

Device: Aries KK 2.5(Affected)
Build ID               20150812230643
Gaia Revision          52f3ea58df38e5427f6afeb636bc6ad01d24022f
Gaia Date              2015-08-12 16:40:43
Gecko Revision         https://hg.mozilla.org/mozilla-central/rev/7649ffe28b67aa2dad0f67ea01500c0ff91b2bac
Gecko Version          43.0a1
Device Name            aries
Firmware(Release)      4.4.2
Firmware(Incremental)  eng.worker.20150812.222959
Firmware Date          Wed Aug 12 22:30:07 UTC 2015
Bootloader             s1
> 3. Using mac try to connect to device via bluetooth.

Use phone to connect can also repro the crash.
QA Whiteboard: [QAnalyst-Triage+] → [QAnalyst-Triage+][MGSEI-Triage+]
Seems reset-gaia wont reset the previous settings. And even after reset the device via settings > device information > reset, the issue is not occurred.

In my test it only happens with flash_pvt gaia + gecko (or full image). Flash gaia only via flash_pvt can't reproduce this issue either. That make debugging pretty hard.


greg, could you spot the issue as video shows in your setup in comment 39? (I think not.) 
Not sure what's different after flash gaia + gecko...
Flags: needinfo?(gasolin) → needinfo?(gweng)
So that I think it somewhat relate to Gecko, since it only happened after flashing Gecko. But as far as I know, it's messy and need to do some profiling to figure out what happened during booting. Especially for first booting.

I'll suggest we to find some Gecko guys to insert some logs in the code, and flash it to watch the value changes. It's already out of LockScreen component, because it now looks like a mozSetting + booting issue.

Ask the "Gecko guys" already in this list. We may need an offline discussion, too.
Flags: needinfo?(gweng) → needinfo?(joliu)
As above discussion, the default `lockscreen.lock` value in settings db should be false. 

Neither FTU nor lockscreen change during booting. So I think we could change the default settings value flashed in build time.
Flags: needinfo?(joliu)
Attachment #8649740 - Flags: review?(rchien)
Attachment #8649740 - Flags: review?(gweng)
Assignee: gweng → gasolin
Attachment #8649740 - Flags: review?(rchien) → review+
Attachment #8649740 - Flags: review?(gweng) → review+
merged https://github.com/mozilla-b2g/gaia/commit/ee58bc4774970dba4b26234a2bc7fd52aaae4bef

thanks
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This issue is verified fixed in Aries 2.5.

Environmental Variables:
Device: Aries 2.5 [Full Flash]
Build ID: 20150819130905
Gaia: 8f77edf3ac39d36f6df0f5517223d3ed35ed89e0
Gecko: d590b9601ba8
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 43.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:43.0) Gecko/43.0 Firefox/43.0

Result:
The connection screen appears and user is able to connect to another bluetooth device.
Status: RESOLVED → VERIFIED
Flags: needinfo?(ktucker)
Flags: needinfo?(ktucker)
Target Milestone: --- → FxOS-S5 (21Aug)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: