[Window Management] Bluetooth transfer requests cannot be accessed when System Update Ready OTA screen is present



Firefox OS
Gaia::System::Window Mgmt
3 years ago
3 years ago


(Reporter: Marty, Unassigned, Mentored)


Gonk (Firefox OS)

Firefox Tracking Flags

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected, b2g-master affected)


(Whiteboard: [3.0-Daily-Testing][lang=js][good first bug], URL)


(1 attachment)



3 years ago
Created attachment 8594150 [details]

If the user has the System Update Ready screen from an OTA when they receive a bluetooth transfer request, attempting to access the transfer request will dismiss the request without opening a transfer screen for the user to accept.  

Repro Steps:
1) Update a Flame to 20150413010203
2) Connect to a WiFi or Data network
3) Enable Bluetooth and pair with a second device.
4) Wait for an OTA to be available in the Notification tray, and download the update.
5) When the update has finished uncompressing and the device displays the System Update Ready screen, transfer a file from the second device to the DUT
6) Attempt to open the Bluetooth Transfer Request from the notification tray or notification banner

The Transfer Request is not opened, and the request notification is dismissed and lost to the user.

The user is able to open the Transfer Request screen.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150413010203
Gaia: 3c68964cb9fdba7cf0f6829b7f44562acaf1f1d7
Gecko: 0a46652bd992
Gonk: b83fc73de7b64594cd74b33e498bf08332b5d87b
Version: 40.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:40.0) Gecko/40.0 Firefox/40.0

Repro frequency: 8/8
See attached: Logcat, Video (URL)

Comment 1

3 years ago
This issue DOES occur on Flame 2.2, 2.1, and 2.0 builds
The Transfer Request is not opened, and the request notification is dismissed and lost to the user.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150416002504
Gaia: 8e24d8b7f5e7c74c3004b22710dda0dac3e04ead
Gecko: 41388836b5c6
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 37.0 (2.2)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

Environmental Variables:
Device: Flame 2.1 (319MB)(Full Flash)
Build ID: 20150416001203
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: c54aa1be51d6
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 34.0 (2.1)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0

Environmental Variables:
Device: Flame 2.0 (319MB)(Full Flash)
Build ID: 20150416000205
Gaia: 84898cadf28b1a1fcd03b726cff658de470282f0
Gecko: bcbd45a97031
Gonk: ebad7da532429a6f5efadc00bf6ad8a41288a429
Version: 32.0 (2.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0
QA Whiteboard: [QAnalyst-Triage?]
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Flags: needinfo?(pbylenga)
NI QA component owner for nomination decision and assignment.
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(pbylenga) → needinfo?(hcheng)
The transfer request screen should be opened and then dismiss the OTA dialog.
Etienne, could you take a look?
Flags: needinfo?(hcheng) → needinfo?(etienne)
Ideally the UpdateManager dialogs and the BluetoothTransfer dialogs should all be SystemDialogs but those are separate and orthogonal bugs.

In the meantime, we should dispatch a |bluetooth-transfer-prompted| CustomEvent when we show the transfer dialog [1] and let the UpdateManager decline the update if needed in this case, like we do when the phone gets locked [2].

[1] https://github.com/mozilla-b2g/gaia/blob/27fe0f4261e3685187769411f2f74cff19287b19/apps/system/js/bluetooth_transfer.js#L192
[2] https://github.com/mozilla-b2g/gaia/blob/27fe0f4261e3685187769411f2f74cff19287b19/apps/system/js/update_manager.js#L763-770
Mentor: etienne@segonzac.info
Flags: needinfo?(etienne)
Whiteboard: [3.0-Daily-Testing] → [3.0-Daily-Testing][lang=js][good first bug]
You need to log in before you can comment on or make changes to this bug.