Support Bluetooth marionette tests for Bluetooth API on B2G emulator-kk

RESOLVED WONTFIX

Status

Firefox OS
Bluetooth
P2
normal
RESOLVED WONTFIX
3 years ago
2 years ago

People

(Reporter: jaliu, Assigned: WillWang)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [EMU] [CI])

Attachments

(7 attachments)

(Reporter)

Description

3 years ago
marionette tests of bluetooth2 were designed to run at real devices.

Since Bluedroid is ready on emulator-kk (Bug 1159625) and bluetooth2 has been switched on (Bug 1167064), we should modify the tests at |dom/bluetooth/bluetooth2/tests/marionette/manifest.ini| to make sure they can pass on B2G emulator-kk.
(Reporter)

Updated

3 years ago
See Also: → bug 1139774
(Reporter)

Updated

3 years ago
See Also: → bug 1175067
(Assignee)

Updated

3 years ago
Assignee: nobody → wiwang

Comment 1

3 years ago
Revise bug title since bluetooth APIv2 is already landed to m-c.
Summary: Support Bluetooth marionette tests for Bluetooth API v2 on B2G emulator-kk → Support Bluetooth marionette tests for Bluetooth API on B2G emulator-kk
(Assignee)

Comment 2

2 years ago
Currently, all bluetooth marionette test cases are followings:

1. [test_dom_BluetoothManager.js]
2. [test_dom_BluetoothAdapter_enable.js]
3. [test_dom_BluetoothAdapter_setters.js]
4. [test_dom_BluetoothDevice.js]
5. [test_dom_BluetoothAdapter_discovery.js]
6. [test_dom_BluetoothAdapter_pair.js]

Test 1,2 are discussed in bug 1139774,
test 3~6 are discussed in this bug.
(Assignee)

Comment 3

2 years ago
Currently, 

test 1,2: PASS in 20 continuous tests (Ref. Bug 1139774 comment 9)
test 3:   PASS in 20 continuous tests (Originally fine, without any modification)
test 4:   Fail [1][2][3]
test 5:   Fail [4]
test 6:   Fail [5]


[1] A javascript syntax error has been identified, and fixed.
[2] Another issue in brief: callback |ondevicefound| in Gecko was instantly called "before" the 
    moment which Gaia's marionette test hooks the corresponding handler.
[3] 3rd identified issue: callback |ondevicefound| will not always correctly called.
[4] Found same issue as [2]
[5] Promise rejected unexpectedly, need investigate root cause.

Updated

2 years ago
Blocks: 1144970

Updated

2 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 4

2 years ago
During solving one of test case, I encountered several issues which prevent emulator-kk from opening b2g correctly after updating all repo.

To solve this, establish a new file under gaia/ and add following two settings into it:

DEVICE_DEBUG=1
NOFTU=1
(Assignee)

Comment 5

2 years ago
I observed that, during startDiscovery() the Gaia will not get a valid discovery handle in time before the qemu return the remote device.[1]

That is,
startDiscovery() firstly is preparing the promise/handle, then fire the discovery action in parallel.
and since the qemu return immediately(<0.01s), in fact the handle in gecko is not set/prepared yet, therefore the received signal in adapter's Notify() will not be processed.

The log in qemu[2] also shows qemu did send the inquiry result back to bluedroid.


[1] 

12-04 12:15:45.940 I/GeckoBluetooth(  942): StartDiscovery: ==== BA: enter
12-04 12:15:45.940 I/GeckoBluetooth(  942): StartDiscovery: ==== BA: call StartDiscoveryInternal (then MAY set handle flag)...
12-04 12:15:45.940 W/bluetoothd( 1000): === b-daemon: enter start_discovery
12-04 12:15:45.940 I/bluedroid( 1000): ==== start_discovery: call btif_dm_start_discovery ...
12-04 12:15:45.940 D/        ( 1000): ==== enter btif_dm_start_discovery
...
12-04 12:15:45.950 D/        ( 1000): ==== call device_found_cb to notify upper
12-04 12:15:45.950 W/bluetoothd( 1000): === b-daemon: enter device_found_cb
...
12-04 12:15:45.960 I/GeckoBluetooth(   65): DistributeSignal: ==== enter, signal name= [DeviceFound]
12-04 12:15:45.960 I/GeckoBluetooth(   65): DistributeSignal: ==== broadcast signal ...
12-04 12:15:45.960 I/GeckoBluetooth(   65): Notify: ==== [A] signal name =[DeviceFound]
...
12-04 12:15:46.120 I/GeckoBluetooth(  942): SetDiscoveryHandleInUse: ==== BA: enter, handle = [0xae605a40]


[2]

==== bt_submit_hci: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_start: enter
==== bt_hci_inquiry_start: ---- for loop call bt_hci_inquiry_result ----
==== bt_hci_inquiry_result: enter
==== bt_hci_inquiry_result_with_rssi: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_result: enter
==== bt_hci_inquiry_result_with_rssi: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_result: enter
==== bt_hci_inquiry_result_with_rssi: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_start: ---- for loop call bt_hci_inquiry_result ---- end
==== bt_hci_event: enter
==== bt_hci_event_start: enter
(Assignee)

Comment 6

2 years ago
(In reply to Will Wang [:WillWang] from comment #5)
> I observed that, during startDiscovery() the Gaia will not get a valid
> discovery handle in time before the qemu return the remote device.[1]
> 

Per comment 3, I observed following 2 tests(which contain discovery action) have this same issue.

4. [test_dom_BluetoothDevice.js]
5. [test_dom_BluetoothAdapter_discovery.js]
(Assignee)

Comment 7

2 years ago
The above issue causing the [test_dom_BluetoothAdapter_discovery.js] failed now can be solved[1] by using the technique we discussed earlier, which is adding a new qemu telnet command to explicitly send out the inquiry result from qemu during the discovering.


[1]

SUITE-START | Running 1 tests
TEST-START | test_dom_BluetoothManager.js
TEST-SKIP | test_dom_BluetoothManager.js | took 0ms
TEST-START | test_dom_BluetoothAdapter_enable.js
TEST-SKIP | test_dom_BluetoothAdapter_enable.js | took 1ms
TEST-START | test_dom_BluetoothAdapter_setters.js
TEST-SKIP | test_dom_BluetoothAdapter_setters.js | took 0ms
TEST-START | test_dom_BluetoothDevice.js
TEST-SKIP | test_dom_BluetoothDevice.js | took 0ms
TEST-START | test_dom_BluetoothAdapter_pair.js
TEST-SKIP | test_dom_BluetoothAdapter_pair.js | took 0ms
TEST-START | test_dom_BluetoothAdapter_discovery.js
TEST-PASS | test_dom_BluetoothAdapter_discovery.js | took 10963ms
START LOG:
INFO TEST-START: /home/will/repooooo/b2ggg/emulator-kk/gecko/dom/bluetooth/tests/marionette/test_dom_BluetoothAdapter_discovery.js Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO navigator.mozBluetooth is available Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO Wait for creating bluetooth adapter... Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO bluetoothManager.defaultAdapter.state: disabled Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO Original state of bluetooth is disabled Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO Enable Bluetooth ... Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO ==== after isnot: BA != null Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO Checking adapter attributes ... Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO adapter.address: 56:34:12:00:54:52 Mon Dec 21 2015 20:01:09 GMT+0800 (UTC)
INFO adapter.name: Full Android on Emulator Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [1] Start discovery and verify the correctness ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO   'discovering' changed to true Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [2] Attach event handler for 'ondevicefound' ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [3] Stop discovery and and verify the correctness ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO   'discovering' changed to false Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [4] Mark the BluetoothDiscoveryHandle from [1] as expired ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [5] Start discovery and verify the correctness ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO   'discovering' changed to true Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [6] Wait for 'devicefound' events ...  Mon Dec 21 2015 20:01:10 GMT+0800 (UTC)
INFO [7] Stop discovery and and verify the correctness ...  Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO   'discovering' changed to false Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO [8] Call 'startDiscovery' twice continuously ...  Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO [9] Call 'stopDiscovery' twice continuously ...  Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO [10] Clean up the event handler of [2] ...  Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO Disable Bluetooth ... Mon Dec 21 2015 20:01:16 GMT+0800 (UTC)
INFO TEST-END: /home/will/repooooo/b2ggg/emulator-kk/gecko/dom/bluetooth/tests/marionette/test_dom_BluetoothAdapter_discovery.js Mon Dec 21 2015 20:01:19 GMT+0800 (UTC)
END LOG:

SUMMARY
-------
passed: 1
failed: 0
(Assignee)

Comment 8

2 years ago
[test_dom_BluetoothDevice.js] now can be resolved after fixing 2 issues:
1. change a misused assertion from is() to isnot()
2. remove UUID check which causes promise rejected

==== Log ====


TEST-START | test_dom_BluetoothDevice.js
TEST-PASS | test_dom_BluetoothDevice.js | took 9772ms
START LOG:
INFO TEST-START: /home/will/repooooo/b2ggg/emulator-kk/gecko/dom/bluetooth/tests/marionette/test_dom_BluetoothDevice.js Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO navigator.mozBluetooth is available Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO Wait for creating bluetooth adapter... Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO bluetoothManager.defaultAdapter.state: disabled Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO Original state of bluetooth is disabled Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO Enable Bluetooth ... Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO ==== after isnot: BA != null Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO Checking adapter attributes ... Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO adapter.address: 56:34:12:00:54:52 Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO adapter.name: Full Android on Emulator Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO [1] Start discovery ...  Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO [2] Wait for 'devicefound' events ...  Tue Dec 22 2015 21:56:12 GMT+0800 (UTC)
INFO [3] Type checking for BluetoothDeviceEvent and BluetoothDevice ...  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO   - BluetoothDevice.address: ba:be:ba:d0:00:02 Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO   - BluetoothDevice.name:  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO   - BluetoothDevice.cod: [object BluetoothClassOfDevice] Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO   - BluetoothDevice.paired: false Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO   - BluetoothDevice.uuids:  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO [4] Attach the 'onattributechanged' handler for the remote device ...  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO [5] Fetch the UUIDs of remote device ...  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO [7] Stop discovery ...  Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO Disable Bluetooth ... Tue Dec 22 2015 21:56:17 GMT+0800 (UTC)
INFO TEST-END: /home/will/repooooo/b2ggg/emulator-kk/gecko/dom/bluetooth/tests/marionette/test_dom_BluetoothDevice.js Tue Dec 22 2015 21:56:21 GMT+0800 (UTC)
END LOG:

SUMMARY
-------
passed: 1
failed: 0
(Assignee)

Comment 9

2 years ago
I observed that one of issues in [test_dom_BluetoothAdapter_pair.js] is accessing the adapter.pairingReqs ,such as hook the handler, will fail the test and crash the whole b2g.


==== Log ====

12-22 21:07:18.883 I/Gecko   (10178): MARIONETTE LOG: INFO: [5] Pair and wait for confirmation ...
12-22 21:07:18.883 I/Gecko   (10178): MARIONETTE LOG: INFO:   - Add event handlers for pairing requests.
12-22 21:07:18.893 I/Gecko   (10178): MARIONETTE LOG: INFO: ==== aAdapter = [object BluetoothAdapter]
12-22 21:07:20.933 I/ServiceManager(   53): service 'SurfaceFlinger' died
12-22 21:07:20.933 I/ServiceManager(   53): service 'permission' died
12-22 21:07:20.933 I/ServiceManager(   53): service 'android.security.keystore' died
12-22 21:07:20.993 I/ServiceManager(   53): service 'media.audio_policy' died
12-22 21:07:20.993 I/ServiceManager(   53): service 'media.audio_flinger' died
12-22 21:07:20.993 I/ServiceManager(   53): service 'media.player' died
12-22 21:07:20.993 I/ServiceManager(   53): service 'media.camera' died
(Assignee)

Comment 10

2 years ago
(In reply to Will Wang [:WillWang] from comment #9)
> I observed that one of issues in [test_dom_BluetoothAdapter_pair.js] is
> accessing the adapter.pairingReqs ,such as hook the handler, will fail the
> test and crash the whole b2g.

I found this may relate to bug 1234127.
(Assignee)

Updated

2 years ago
See Also: → bug 1234127
(Assignee)

Comment 11

2 years ago
(In reply to Will Wang [:WillWang] from comment #10)
> (In reply to Will Wang [:WillWang] from comment #9)
> > I observed that one of issues in [test_dom_BluetoothAdapter_pair.js] is
> > accessing the adapter.pairingReqs ,such as hook the handler, will fail the
> > test and crash the whole b2g.
> 
> I found this may relate to bug 1234127.

I have confirmed this relationship, now the marionette test can access |pairingReqs| and hook handler once |IsBluetoothCertifiedApp| check is removed.

Besides,
If applying the patch in bug 1234127, marionette test can get a null |pairingReqs| object and will not crash the test and b2g.
(Assignee)

Comment 12

2 years ago
Test case summary:

1. [test_dom_BluetoothManager.js]            OK
2. [test_dom_BluetoothAdapter_enable.js]     OK
3. [test_dom_BluetoothAdapter_setters.js]    OK
4. [test_dom_BluetoothDevice.js]             OK  
5. [test_dom_BluetoothAdapter_discovery.js]  OK
6. [test_dom_BluetoothAdapter_pair.js]       Investigating
(Assignee)

Comment 13

2 years ago
For |IsBluetoothCertifiedApp| check in [test_dom_BluetoothAdapter_pair.js], 
I am working on modifying the app origin of marionette test during the test process.
(Assignee)

Comment 14

2 years ago
During the issue solving, I observed that sometimes Adapter.enabled() will fail since adapter state at that time is "disabling" instead of the expected "disabled".

This seems to be caused by adapter disabling incompleteness.


==== Log ====

 70 12-24 10:02:40.678 I/Gecko   (   65): MARIONETTE LOG: INFO: bluetoothManager.defaultAdapter.state: enabled
 71 12-24 10:02:40.688 I/Gecko   (   65): MARIONETTE LOG: INFO: Original state of bluetooth is enabled
 72 12-24 10:02:40.688 I/Gecko   (   65): MARIONETTE LOG: INFO: Disable Bluetooth ...
......

 74 12-24 10:02:40.718 I/GeckoBluetooth(   65): Disable: ==== BA: enter
 75 12-24 10:02:40.718 I/GeckoBluetooth(   65): Disable: ==== BA: mState =[2] (disabled=0,disabling,enabled,enabling)
 76 12-24 10:02:40.718 I/GeckoBluetooth(   65): Disable: ==== BA: Set adapter state to Disabling
......

118 12-24 10:02:44.028 I/GeckoBluetooth(   65): Enable: ==== BA: enter
119 12-24 10:02:44.028 I/GeckoBluetooth(   65): Enable: ==== BA: mState =[1] (disabled=0,disabling,enabled,enabling)
120 12-24 10:02:44.028 I/GeckoBluetooth(   65): Enable: BT_ENSURE_TRUE_REJECT(mState == BluetoothAdapterState::Disabled) failed
121 12-24 10:02:44.028 I/Gecko   (   65): MARIONETTE LOG: INFO: ==== BA enable rejected
(Assignee)

Updated

2 years ago
See Also: → bug 1234974
(Assignee)

Comment 15

2 years ago
Created attachment 8701717 [details] [review]
Pull Request of Qemu on github b2g repo

Hi Shawn,

Could you help to review this pull request?
Thanks!
Attachment #8701717 - Flags: review?(shuang)
Comment on attachment 8701717 [details] [review]
Pull Request of Qemu on github b2g repo

Hi Will,
This revision looks like better and it looks like good to me.
Attachment #8701717 - Flags: review?(shuang) → review+
(Assignee)

Updated

2 years ago
Keywords: checkin-needed
(Assignee)

Comment 17

2 years ago
Created attachment 8701812 [details]
Log: adapter enable timing issue

(In reply to Will Wang [:WillWang] from comment #14)
> During the issue solving, I observed that sometimes Adapter.enabled() will
> fail since adapter state at that time is "disabling" instead of the expected
> "disabled".

More info investigated:

For adapter disable(), adapter state update is delayed and occurs after resolving promise.(132 12-24 18:05:58.030)

Thus, once enable() starts, its adapter state check fails.(116 12-24 18:05:57.970)

==== Log ====

 56 12-24 18:05:54.630 I/Gecko   (   65): MARIONETTE LOG: INFO: bluetoothManager.defaultAdapter.state: enabled
 57 12-24 18:05:54.630 I/Gecko   (   65): MARIONETTE LOG: INFO: Original state of bluetooth is enabled
 58 12-24 18:05:54.630 I/Gecko   (   65): MARIONETTE LOG: INFO: Disable Bluetooth ...
 59 12-24 18:05:54.690 I/Gecko   (   65): MARIONETTE TEST RESULT:TEST-PASS | test_dom_BluetoothAdapter_pair.js | bluetoothManager.defaultAdapter - [object BluetoothAdapte    r] should not equal null
 60 12-24 18:05:54.690 I/GeckoBluetooth(   65): Disable: ==== BA: enter
 61 12-24 18:05:54.690 I/GeckoBluetooth(   65): Disable: ==== BA: mState =[2] (disabled=0,disabling,enabled,enabling)
 62 12-24 18:05:54.700 I/GeckoBluetooth(   65): Disable: ==== BA: Set adapter state to Disabling
 63 12-24 18:05:54.700 I/GeckoBluetooth(   65): SetAdapterState: ==== BA: now SetAdapterState to =[1] (disabled=0,disabling,enabled,enabling)
......

 94 12-24 18:05:57.930 I/GeckoBluetooth(   65): AdapterStateChangedNotification: BT_STATE: 0
 95 12-24 18:05:57.930 I/GeckoBluetooth(   65): DistributeSignal: ==== enter, signal name= [PropertyChanged]
......

111 12-24 18:05:57.940 I/GeckoBluetooth(   65): AdapterStateChangedNotification: ==== BSB: Resolve promise if existed
......

114 12-24 18:05:57.970 I/GeckoBluetooth(   65): Enable: ==== BA: enter
115 12-24 18:05:57.970 I/GeckoBluetooth(   65): Enable: ==== BA: mState =[1] (disabled=0,disabling,enabled,enabling)
116 12-24 18:05:57.970 I/GeckoBluetooth(   65): Enable: BT_ENSURE_TRUE_REJECT(mState == BluetoothAdapterState::Disabled) failed
117 12-24 18:05:57.980 I/Gecko   (   65): MARIONETTE LOG: INFO: ==== BA enable rejected
......

125 12-24 18:05:58.020 I/GeckoBluetooth(   65): AcknowledgeToggleBt: ==== BA: enter
126 12-24 18:05:58.030 I/GeckoBluetooth(   65): CompleteToggleBt: ==== BA: enter
127 12-24 18:05:58.030 I/GeckoBluetooth(   65): CompleteToggleBt: ==== BA: enter
128 12-24 18:05:58.030 I/GeckoBluetooth(   65): DistributeSignal: ==== enter, signal name= [PropertyChanged]
129 12-24 18:05:58.030 I/GeckoBluetooth(   65): DistributeSignal: ==== broadcast signal ...
130 12-24 18:05:58.030 I/GeckoBluetooth(   65): Notify: ==== [A] signal name =[PropertyChanged]
131 12-24 18:05:58.030 I/GeckoBluetooth(   65): HandlePropertyChanged: ==== BA: enter
132 12-24 18:05:58.030 I/GeckoBluetooth(   65): SetPropertyByValue: ==== BA: set mState to [0]
......
(Assignee)

Comment 18

2 years ago
(In reply to Will Wang [:WillWang] from comment #17)
> More info investigated:
> 
> For adapter disable(), adapter state update is delayed and occurs after
> resolving promise.(132 12-24 18:05:58.030)
> 
> Thus, once enable() starts, its adapter state check fails.(116 12-24
> 18:05:57.970)

To speedup issue solving, I temporarily add a setTimeout function(3000ms) between disable() and enable(),
this works[1] and can make us more focus to the marionette test itself.
Moreover, this can also supports our observation/speculation about the timing.

[1]

 52 12-24 21:37:20.620 I/GeckoBluetooth(   65): Disable: ==== BA: enter
 53 12-24 21:37:20.620 I/GeckoBluetooth(   65): Disable: ==== BA: mState =[2] (disabled=0,disabling,enabled,enabling)
 54 12-24 21:37:20.620 I/GeckoBluetooth(   65): Disable: ==== BA: Set adapter state to Disabling
 55 12-24 21:37:20.620 I/GeckoBluetooth(   65): SetAdapterState: ==== BA: now SetAdapterState to =[1] (disabled=0,disabling,enabled,enabling)
......

 97 12-24 21:37:23.850 I/GeckoBluetooth(   65): AdapterStateChangedNotification: ==== BSB: Resolve promise if existed
......

113 12-24 21:37:23.860 I/GeckoBluetooth(   65): SetPropertyByValue: ==== BA: set mState to [0]
......

123 12-24 21:37:26.870 I/Gecko   (   65): MARIONETTE LOG: INFO: ==== time is up, resolve promise.
124 12-24 21:37:26.870 I/Gecko   (   65): MARIONETTE LOG: INFO: Enable Bluetooth ...
......
126 12-24 21:37:26.900 I/GeckoBluetooth(   65): Enable: ==== BA: enter
127 12-24 21:37:26.900 I/GeckoBluetooth(   65): Enable: ==== BA: mState =[0] (disabled=0,disabling,enabled,enabling)
128 12-24 21:37:26.900 I/GeckoBluetooth(   65): Enable: ==== BA: Set adapter state to enabling
129 12-24 21:37:26.900 I/GeckoBluetooth(   65): SetAdapterState: ==== BA: now SetAdapterState to =[3] (disabled=0,disabling,enabled,enabling)
(Assignee)

Comment 19

2 years ago
Hi Edgar,

Try result looks good :)
https://treeherder.mozilla.org/#/jobs?repo=try&revision=6891a0d4d161

Thanks for your help!
Flags: needinfo?(echen)
(Assignee)

Comment 20

2 years ago
Created attachment 8702165 [details]
Log: HCI_SIMPLE_PAIRING_SUPPORTED in bluedroid stack is false

I monitored all HCI events received between qemu and stack, and traced the internal behavior of bluedroid stack, found that the reason of |PinRequestNotification| in gecko got called(we expect |SspRequestNotification| instead) should be |HCI_SIMPLE_PAIRING_SUPPORTED| in bluedroid is false.

This finding also supports our observation that all HCI events we implemented in qemu for Secure Simple Pairing(SSP) are not called at all, so I suppose the SSP is not enabled in earlier stage.

Besides, I consider this even don't relate to the "IO Capability Exchange" step, which is also a factor of pairing algorithm decision but in different phase.


==== Log ====

 752 12-28 06:40:05.608 I/GeckoBluetooth(   65): PairUnpair: ==== BA: enter PairUnpair
 753 12-28 06:40:05.608 I/GeckoBluetooth(   65): CreatePairedDeviceInternal: ==== enter
 754 12-28 06:40:05.608 I/bt-btif ( 1012): btif_dm_create_bond: bd_addr=ba:be:ba:d0:00:02
......
 773 12-28 06:40:05.608 I/bt-btm  ( 1012): ==== enter: BTM_SecBond BDA: ba:be:ba:d0:00:02
......
 782 12-28 06:40:05.608 D/bt-btm  ( 1012): after update sec_flags=0x80
 783 12-28 06:40:05.608 I/bt-btm  ( 1012): ==== HCI_SIMPLE_PAIRING_SUPPORTED is false
......
 790 12-28 06:40:05.608 I/bt-btm  ( 1012): BTM_SecBond: Remote sm4: 0x0  HCI Handle: 0xffff
 791 12-28 06:40:05.608 D/bt-btm  ( 1012): sec mode: 2 sm4:x0
 792 12-28 06:40:05.608 I/bt-btm  ( 1012): ==== HCI_SIMPLE_PAIRING_SUPPORTED is false
 793 12-28 06:40:05.608 I/bt-btm  ( 1012): btm_sec_change_pairing_state  Old: 0
 794 12-28 06:40:05.608 I/bt-btm  ( 1012): btm_sec_change_pairing_state  New: 3 pairing_flags:0x1
 795 12-28 06:40:05.608 D/bt-btm  ( 1012): btm_sec_check_prefetch_pin: PIN code callback called
......
 824 12-28 06:40:05.618 I/bt-btif ( 1012): btif_dm_upstreams_cback  ev: BTA_DM_PIN_REQ_EVT
......
 862 12-28 06:40:05.618 I/bt-btif ( 1012): HAL bt_hal_cbacks->pin_request_cb
......
 874 12-28 06:40:05.668 I/GeckoBluetooth(   65): PinRequestNotification: ==== enter
......
 877 12-28 06:40:05.668 I/Gecko   (   65): MARIONETTE LOG: INFO: ==== enter aAdapter.pairingReqs.onenterpincodereq
 878 12-28 06:40:05.668 I/Gecko   (   65): MARIONETTE LOG: INFO:   - Received 'onenterpincodereq' event.
 879 12-28 06:40:05.668 I/Gecko   (   65): MARIONETTE LOG: INFO: ==== device = undefined
(Assignee)

Comment 21

2 years ago
Bluetooth Core spec > volume 2 > part F > 4.2.6 Start Simple Pairing:

"Once the host has determined that simple pairing should start, it issues an Authentication Requested command to the controller."

Comment 22

2 years ago
Does pairing confirmation flow work normally after HCI_SIMPLE_PAIRING_SUPPORTED is enabled? Also what do we plan to fix the problem, by enabling HCI_SIMPLE_PAIRING_SUPPORTED on emulator or ?

(In reply to Will Wang [:WillWang] from comment #20)
> Created attachment 8702165 [details]
> Log: HCI_SIMPLE_PAIRING_SUPPORTED in bluedroid stack is false
> 
> I monitored all HCI events received between qemu and stack, and traced the
> internal behavior of bluedroid stack, found that the reason of
> |PinRequestNotification| in gecko got called(we expect
> |SspRequestNotification| instead) should be |HCI_SIMPLE_PAIRING_SUPPORTED|
> in bluedroid is false.
> 
> This finding also supports our observation that all HCI events we
> implemented in qemu for Secure Simple Pairing(SSP) are not called at all, so
> I suppose the SSP is not enabled in earlier stage.
Flags: needinfo?(wiwang)
(Assignee)

Comment 23

2 years ago
Since following log shows that |HCI_SIMPLE_PAIRING_SUPPORTED| feature of local host is false (according to core spec[1]):

 791 12-28 06:40:05.608 D/bt-btm  ( 1012): sec mode: 2 sm4:x0
 792 12-28 06:40:05.608 I/bt-btm  ( 1012): ==== HCI_SIMPLE_PAIRING_SUPPORTED is false


Experiment: I temporarily enforce the |HCI_SIMPLE_PAIRING_SUPPORTED| as true

Result: The pairing algorithm switch to SSP(Just works) from legacy pairing(pin code) [2], and many expected HCI events within qemu are consequently called.[3] (although the marionette test is not completely passed)

I am going to fix the |HCI_SIMPLE_PAIRING_SUPPORTED| as your suggestion.


[1] core spec, vol-3, part C(GAP): "A device may support two security modes simultaneously: security mode 2 for backwards compatibility with remote devices that do not support Secure Sim- ple Pairing and security mode 4 for devices that support Secure Simple Pair- ing."


[2] 
 829 12-28 11:21:09.533 I/bt-btm  ( 1043): Security Manager: Start authentication
...
 893 12-28 11:21:09.543 I/bt-btif ( 1043): btif_dm_ssp_cfm_req_evt: Auto-accept JustWorks pairing
...
 918 12-28 11:21:09.543 I/bt-btm  ( 1043): btm_sec_link_key_notification()  BDA:babebad00002, TYPE: 5
...
 923 12-28 11:21:09.543 D/bt-btif ( 1043): btif_dm_auth_cmpl_evt: Storing link key. key_type=0x5, is_temp=0


[3]
==== bt_submit_hci: enter case OCF_AUTH_REQUESTED
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_request_link_key: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: enter case OCF_LINK_KEY_NEG_REPLY
==== bt_hci_event_start: enter
==== bt_hci_request_io_capability: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: enter case OCF_IO_CAPABILITY_REQ_REPLY
==== bt_hci_event_start: enter
==== bt_hci_response_io_capability: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_request_user_confirmation: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: case OCF_REMOTE_NAME_REQ
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: enter case OCF_USER_CONFIRMATION_REQ_REPLY
==== bt_hci_event_start: enter
==== bt_hci_complete_simple_pairing: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_notify_link_key: enter
Flags: needinfo?(wiwang)
(Assignee)

Comment 24

2 years ago
Hi Edgar,

Updated try result:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=010d8dc480d2

Thanks for your support :)
https://github.com/mozilla-b2g/platform_external_qemu/commit/8f23f8a4677a21019b0e50a590716d37df7d1cb1
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
(Assignee)

Comment 27

2 years ago
Tomcat thanks :) bug is still under resolving
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [EMU] [CI]
(Assignee)

Comment 28

2 years ago
Some stack and qemu logic[1] about the Secure Simple Pairing(SSP) are clarified, and I encountered a strange thing:

Once I set the SSP feature bit, it fails the bluetooth enablement and block other ongoing HCI commands.
Besides,
- I tried to set several other bits in same byte and it won't behave as above.
- Set the |HCI_SIMPLE_PAIRING_SUPPORTED| as true directly will fail, either.
- Set the SSP feature bit(Host) as true in both stack or qemu side will fail, either.

I have tried to track the influence of SSP feature bit, however I am thinking and searching for a more effective way.

[1]
- To support SSP, both host and controller need support, furthermore, both local and remote device need support as well.
- Bluedroid choose pairing mode according to the |HCI_SIMPLE_PAIRING_SUPPORTED| and security mode, then these two factors are decided by LMP feature, so the LMP feature is key.
- Bluedroid read LMP feature by issuing HCI command either |Read Local Supported Features| or |Read Local Extended Features Command| (refer to |btm_get_local_features|), and my experiments show that the extended one include the basic one. So the extended one is key.
- Our case use the extended one to read feature, and related functions and data structures in both stack and qemu are identified. (so we don't need to consider the data structure of basic feature bit)
- Byte order of LMP feature are considered and examined.
Whiteboard: [EMU] [CI]
(Assignee)

Updated

2 years ago
Whiteboard: [EMU] [CI]
(Assignee)

Updated

2 years ago
Status: REOPENED → ASSIGNED
(Assignee)

Comment 29

2 years ago
(In reply to Will Wang [:WillWang] from comment #28)
> Some stack and qemu logic[1] about the Secure Simple Pairing(SSP) are
> clarified, and I encountered a strange thing:
> 
> Once I set the SSP feature bit, it fails the bluetooth enablement and block
> other ongoing HCI commands.
> Besides,

Detail of above comment:

After bluedroid issued the HCI command "HCI_Read_Local_ Extended_Features"(BT Core spec > vol 2 > 7.4.4),
controller(qemu) correctly send back SSP feature bit which is modified as 0x08 by me.

And observation found that pairing flow get stucked after bluedroid issued the HCI command "HCI_Write_Simple_Pairing_Mode"(BT Core spec > vol 2 > 7.3.59), with a timeout warning in the log [1].

To solve this stuck, within qemu, I add a case of HCI command for this(HCI_Write_Simple_Pairing_Mode) including replying a "Command Complete Event"(BT Core spec > vol 2 > 7.7.14), then pairing flow now can continue to go further after inquiry [2], and log shows no warning for that and status of HCI_Write_Simple_Pairing_Mode changed[3].

Currently I am keeping pushing the pairing flow forward by observing whether the HCI command/event is absent or not.



[1]

01-06 19:47:29.979 E/bt-hci  ( 1024): ==== [btu_hcif_hdl_command_complete]: enter, case = HCI_READ_LOCAL_EXT_FEATURES
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: enter
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][0] =0x[5f]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][1] =0x[35]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][2] =0x[85]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][3] =0x[7e]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][4] =0x[9b]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][5] =0x[19]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][6] =0x[8]
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_read_local_ext_features_complete]: local_lmp_features[0][7] =0x[80]
01-06 19:47:29.979 D/bt-btm  ( 1024): BTM reached last extended features page (0)
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_set_lmp_features_host_may_support]: enter
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_set_lmp_features_host_may_support]: enter 111
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_set_lmp_features_host_may_support]: enter 444
01-06 19:47:29.979 D/bt-btm  ( 1024): btm_issue_host_support_for_lmp_features lmp_features_host_may_support: 0x03
01-06 19:47:29.979 D/bt-btm  ( 1024): ==== [btm_issue_host_support_for_lmp_features]: enter
01-06 19:47:37.959 E/BTLD    ( 1024): ######################################################################
01-06 19:47:37.959 E/BTLD    ( 1024): #
01-06 19:47:37.959 E/BTLD    ( 1024): # WARNING : BTU HCI(id=0) command timeout. opcode=0xc56
01-06 19:47:37.959 E/BTLD    ( 1024): #
01-06 19:47:37.959 E/BTLD    ( 1024): ######################################################################
01-06 19:47:37.959 E/bt-hci  ( 1024): ==== [btu_hcif_cmd_timeout]: calling btu_hcif_hdl_command_complete ... 
01-06 19:47:37.959 E/bt-hci  ( 1024): ==== [btu_hcif_hdl_command_complete]: enter
01-06 19:47:37.959 W/bt-btm  ( 1024): btm_write_simple_paring_mode_complete status: 0x1f

[2]

==== bt_submit_hci: case OCF_READ_LOCAL_EXT_FEATURES
bt_hci_read_local_ext_features_rp: enter
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: case OCF_WRITE_SIMPLE_PAIRING_MODE
==== bt_hci_event_start: enter
==== bt_submit_hci: enter
==== bt_submit_hci: case OCF_READ_LOCAL_EXT_FEATURES
bt_hci_read_local_ext_features_rp: enter
......
......
==== bt_hci_inquiry_start: ---- for loop call bt_hci_inquiry_result ----
==== bt_hci_inquiry_result: enter
==== bt_hci_inquiry_result_with_rssi: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_result: enter
==== bt_hci_inquiry_result_with_rssi: enter
==== bt_hci_event: enter
==== bt_hci_event_start: enter
==== bt_hci_inquiry_start: ---- for loop call bt_hci_inquiry_result ---- end
==== bt_submit_hci: enter


[3]
01-07 19:11:30.810 W/bt-btm  ( 1094): btm_write_simple_paring_mode_complete status: 0x01
(Assignee)

Comment 30

2 years ago
Created attachment 8706239 [details]
Log: HCI command "Write simple pairing mode" added

Log for above comment: after adding the HCI command "Write simple pairing mode"
(In reply to Will Wang [:WillWang] from comment #30)
> Created attachment 8706239 [details]
> Log: HCI command "Write simple pairing mode" added
> 
> Log for above comment: after adding the HCI command "Write simple pairing
> mode"

I don't understand the log. You said it's SSP but why should i see pin_request_cb?
Why?

"01-07 19:11:32.440 I/bt-btif ( 1094): HAL bt_hal_cbacks->pin_request_cb"

01-07 19:11:32.440 I/Gecko   (   64): MARIONETTE LOG: INFO: ==== enter aAdapter.pairingReqs.onenterpincodereq
01-07 19:11:32.440 I/Gecko   (   64): MARIONETTE LOG: INFO:   - Received 'onenterpincodereq' event.
01-07 19:11:32.440 I/Gecko   (   64): MARIONETTE LOG: INFO: ==== device = undefined
01-07 19:12:19.780 I/bt-btm  ( 1094): btm_sec_pairing_timeout()  State: 3   Flags: 9
Ben, do you have progress on this bug? Can you update if any?
Flags: needinfo?(btian)
(Assignee)

Comment 33

2 years ago
(In reply to Ethan Tseng [:ethan] from comment #32)
> Ben, do you have progress on this bug? Can you update if any?

Hi Ethan,

Currently 5 of all 6 bluetooth test cases are solved, the last one is under investigating.

1. [test_dom_BluetoothManager.js]            OK, Code landed
2. [test_dom_BluetoothAdapter_enable.js]     OK, Code landed
3. [test_dom_BluetoothAdapter_setters.js]    OK, Code landed
4. [test_dom_BluetoothDevice.js]             OK, Patch will be sent to review soon
5. [test_dom_BluetoothAdapter_discovery.js]  OK, Patch will be sent to review soon
6. [test_dom_BluetoothAdapter_pair.js]       Investigating, will be resolved by end of January

Thanks!
Flags: needinfo?(btian)
Thank you Will for prompt response!
(In reply to Will Wang [:WillWang] from comment #29)
> (In reply to Will Wang [:WillWang] from comment #28)
> > Some stack and qemu logic[1] about the Secure Simple Pairing(SSP) are
> > clarified, and I encountered a strange thing:
> > 
> > Once I set the SSP feature bit, it fails the bluetooth enablement and block
> > other ongoing HCI commands.
> > Besides,
> 
> Detail of above comment:
> 
> After bluedroid issued the HCI command "HCI_Read_Local_
> Extended_Features"(BT Core spec > vol 2 > 7.4.4),
> controller(qemu) correctly send back SSP feature bit which is modified as
> 0x08 by me.
> 
> And observation found that pairing flow get stucked after bluedroid issued
> the HCI command "HCI_Write_Simple_Pairing_Mode"(BT Core spec > vol 2 >
> 7.3.59), with a timeout warning in the log [1].
> 
> To solve this stuck, within qemu, I add a case of HCI command for
> this(HCI_Write_Simple_Pairing_Mode) including replying a "Command Complete
> Event"(BT Core spec > vol 2 > 7.7.14), then pairing flow now can continue to
> go further after inquiry [2], and log shows no warning for that and status
> of HCI_Write_Simple_Pairing_Mode changed[3].
> 
> Currently I am keeping pushing the pairing flow forward by observing whether
> the HCI command/event is absent or not.
For me, the problem doesn't look like related to ACL connection but it looks like that the remote device record doesn't have sm4. So sm4 is unknown.
Checking the stack, sm4 would be assigned in |btm_sec_rmt_host_support_feat_evt|.

Remote Host Supported Features Notification Event, Event Code is 0x3D.
When the Controller receives the Remote_Name_Request command, the Con-
troller sends the Command Status event to the Host. When the Link Manager
has completed the LMP messages to obtain the remote host supported fea-
tures, if present, the Controller on the local Bluetooth device will send a
Remote Host Supported Features Notification event. When the Link Manager
has completed the LMP messages to obtain the remote name, the Controller
on the local Bluetooth device will send a Remote Name Request Complete
event to the Host. If the remote host supported features page is present, the
Remote Host Supported Features Notification event will be sent before the
Remote Name Request Complete event. If not, only the Remote Name
Request Complete event will be sent.
Note: no Command Complete event will be sent by the Controller to indicate
that this command has been completed. Instead, only the Remote Name
Request Complete event will indicate that this command has been completed.

So we suppose to see:
Command     Remote_Name_Request
Event       Remote_Name_Request                                   Status->Success
Event       Remote Host Supported Features Notification Event
Event       Remote_Name_Request Complete                          Success->Success

bluedroid assumes without HCI_RMT_HOST_SUP_FEAT_NOTIFY_EVT, it's very old legacy device.

We shall send 'Remote Host Supported Features Notification Event before replying Remote_Name_Request_Completed in qemu.

See:
https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/5738f83aeb59361a0a2eda2460113f6dc9194271/stack/btm/btm_sec.c#2906
(Assignee)

Comment 36

2 years ago
Created attachment 8709396 [details] [diff] [review]
Patch: Fix test_dom_BluetoothDevice.js and test_dom_BluetoothAdapter_discovery.js

Hi Ben,

This patch fix following marionette test cases:
1. test_dom_BluetoothDevice.js (refer to comment 8)
2. test_dom_BluetoothAdapter_discovery.js (refer to comment 7)

and also have them enabled in the manifest.ini.

This patch is tested for many times and the latest test log will be attached in next comment. 

Could you help to review this patch?
Thanks!

Additionally, for better reliability, I wrote a script to test this patch for 100 times continuously. The result and log will be posted once it's done.
Attachment #8709396 - Flags: review?(btian)
(Assignee)

Comment 37

2 years ago
Created attachment 8709397 [details]
Log(zip): marionette running log for comment 36

Log for above comment 36.
(Assignee)

Comment 38

2 years ago
(In reply to Will Wang [:WillWang] from comment #18)
> To speedup issue solving, I temporarily add a setTimeout function(3000ms)
> between disable() and enable(),
> this works[1] and can make us more focus to the marionette test itself.
> Moreover, this can also supports our observation/speculation about the
> timing.

Note: 

This setTimeout function will not be needed if emulator program is re-launched every time for each marionette test suite.

For example: 
If we run the "./mach marionette-webapi gecko/dom/bluetooth/tests/marionette/manifest.ini" for many times,
then setTimeout function will not be needed.

On the contrary,
If we keep the emulator program running without re-launch it, and repetitively issue the marionette test by commment such as
"~/pyEnv/bin/python testing/marionette/client/marionette/runtests.py --address=localhost:2828 --type=b2g dom/bluetooth/tests/marionette/manifest.ini",
then setTimeout function will be needed as comment 17 and comment 18 mentioned.
(Assignee)

Comment 39

2 years ago
Created attachment 8709604 [details]
Log: test100-log.zip

(In reply to Will Wang [:WillWang] from comment #36)
> Additionally, for better reliability, I wrote a script to test this patch
> for 100 times continuously. The result and log will be posted once it's done.

Continuously 100 tests for this patch are all passed. 
No test was failed.

100 log files are as attached.

Note: The script of performing 100 tests for reference:

for ((n=1;n<=100;n++))
do
 echo ===================== $n ======================
 ./mach marionette-webapi gecko/dom/bluetooth/tests/marionette/manifest.ini 2>&1 | tee test100-log/mnw-$n.log
 echo
done
(Assignee)

Updated

2 years ago
Depends on: 1240989
(Assignee)

Comment 40

2 years ago
Comment on attachment 8709396 [details] [diff] [review]
Patch: Fix test_dom_BluetoothDevice.js and test_dom_BluetoothAdapter_discovery.js

Cancel the review? since another bug 1240989 is opened for further related actions.
Attachment #8709396 - Flags: review?(btian)
(Assignee)

Updated

2 years ago
Depends on: 1240992
(Assignee)

Updated

2 years ago
Depends on: 1240997
(In reply to Shawn Huang [:shawnjohnjr] from comment #35)
> (In reply to Will Wang [:WillWang] from comment #29)
> We shall send 'Remote Host Supported Features Notification Event before
> replying Remote_Name_Request_Completed in qemu.
> 
> See:
> https://android.googlesource.com/platform/external/bluetooth/bluedroid/+/
> 5738f83aeb59361a0a2eda2460113f6dc9194271/stack/btm/btm_sec.c#2906
I've tested Comment #35, my suspicion seems to be correct. 
see: Bug 1241041 - [emulator] Support secure simple pairing for qemu correctly
But even bug 1241041 fix the SSP problem, the SDP procedure seems to be invalid. I saw one SDP packet is not correct, which makes bluedroid never send callbacks.

Updated

2 years ago
Depends on: 1241052

Updated

2 years ago
No longer depends on: 1241052

Updated

2 years ago
No longer depends on: 1241041

Updated

2 years ago
Priority: -- → P2

Comment 42

2 years ago
Resolve as WONTFIX since B2G is discontinued.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.