1160667 - [Window Management] OTA becomes inaccessible if the screen turns off when the 'System Update Available' screen is active.

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System::Window Mgmt, defect)

Description

[Martin Shuman [:Marty]]

Attachment: logcat-ota-lockscreen.txt

Description:
If the screen turns off when the 'System Update Available' screen is active, this screen will dismiss when the user unlocks the device. The user is unable to reacquire the update screen from the Notification Tray, because the OTA still displays as 'Uncompressing...' and does not respond to user input.

Note: This issue does not occur if the update finishes uncompressing WHILE the device is locked, only if it finishes while the device is unlocked, and is then locked afterwards while the screen is active.

Repro Steps:
1) Update a Flame to 20150430010201
2) Connect to a WiFi or Data network and wait for the update to become available.
3) Download the update. Ensure that the device is unlocked when the update finishes uncompressing.
4) Once the update has uncompressed and the 'System Update Available' screen is present, either let the screen time-out or manually lock the device with the Power button.

Actual:
The update screen is dismissed, and the OTA is inaccessible in the Notification Tray.

Expected:
The update screen remains present after unlocking the device and the OTA is still accessible in the Notification Tray.

Environmental Variables:
Device: Flame 3.0  (319MB)(Full Flash)
Build ID: 20150430010201
Gaia: db8ea705c0fd1b1684807f5a8e837bb9a36a6f96
Gecko: 4b9b12c248dc
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: 5/5
See attached: logcat, video (URL)

Comment 1

[Martin Shuman [:Marty]]

This issue DOES occur on Flame 2.2 builds.
The update screen is dismissed, and the OTA is inaccessible in the Notification Tray.

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150430002504
Gaia: aa1da5036f9425c25d515d14243d3473bfefb4fd
Gecko: 38b2838d43e1
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

This issue does NOT occur on Flame 2.1 builds.
The update screen remains present after unlocking the device and the OTA is still accessible in the Notification Tray.

Environmental Variables:
Device: Flame 2.1 (319MB)(Full Flash)
Build ID: 20150424001201
Gaia: bbe983b4e8bebfec26b3726b79568a22d667223c
Gecko: 6a68a038146a
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

Comment 2

[Peter Bylenga [:PBylenga]]

OTA being unaccessible in uncompressing state was an intended change.  However this is still a functional regression where the OTA screen isn't present after lock/unlocking.

Requesting a window.

Comment 3

[Brogan Zumwalt [Inactive]]

Issue reproduces on the earliest mozilla-central-flame-kk build from PVT. Unable to provide a regression window.

Following STR, the update is ready to apply page vanishes after turning screen off then on again once update finishes uncompressing.

Device: Flame 3.0
Build ID: 20150206163055
Gaia: a0e71e61922bde009a3b6714cbe965021d3279f1
Gecko: f8ce4cf2e71d
Gonk: e7c90613521145db090dd24147afd5ceb5703190
Version: 38.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:38.0) Gecko/38.0 Firefox/38.0

Comment 4

[Gregor Wagner [:gwagner]]

Mike, can you take a look?

Comment 5

[:gerard-majax]

I already filed this as bug 1148452 :(

Comment 7

[GitHub Autolander Bot]

Attachment: [gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

Comment 8

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8601137 [details] [review]
[gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

Etienne, the problem is that when the "System Update Ready" dialog pops up, the notification still exists in the utility tray until the system updatable removes itself from the download queue in the download manager. The unfortunate part here is that all update prompts use the CustomDialog singleton, so calling CustomDialog.hide() whenever the lockscreen is opened kills the System Update Ready dialog without cleaning up the notifications and preparing for a re-install. My proposed solution is to check for the specific occurrence of the system update dialog, and to basically invoke the same functionality as the "Install Later" button. What do you think of this approach?

Comment 9

[Etienne Segonzac (:etienne)]

Comment on attachment 8601137 [details] [review]
[gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

Makes perfect sense!

nit: maybe we should model a `systemUpdatable.showingApplyPrompt` after `systemUpdatable.paused` (ie. part of the constructor, no getter etc...)

Comment 10

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8601137 [details] [review]
[gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

Addressed nit, added a unit test.

Comment 11

[Etienne Segonzac (:etienne)]

Comment on attachment 8601137 [details] [review]
[gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

all good!

Comment 12

[GitHub Autolander Bot]

Pull request has landed in master: https://github.com/mozilla-b2g/gaia/commit/6935d980249b74b98c6e9c6a615a4f0e5b00f222

Comment 13

[Michael Henretty [:mikehenrty][:mhenretty]]

Comment on attachment 8601137 [details] [review]
[gaia] mikehenrty:bug-1160667-cancel-install > mozilla-b2g:master

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #):
Not technically a regression, but bug 1155704 made it easier to reproduce this bug.

[User impact] if declined:
User can get stuck in a state where they cannot finish and install an update which has already been downloaded.

[Testing completed]:
Manually tested and added a unit test.

[Risk to taking this patch] (and alternatives if risky):
The risk is to the system update mechanism, so we should probably verify this on master before uplifting.


[String changes made]: none.

Comment 14

[Ryan VanderMeulen [:RyanVM]]

v2.2: https://github.com/mozilla-b2g/gaia/commit/b03899a35642b9b4c155becbbbab4fe75a7d8590

Comment 15

[Hermes Cheng (inactive after July 27, 2015)]

Could you help verify?

Comment 16

[Martin Shuman [:Marty]]

This issue is verified fixed on the latest Flame 3.0 builds.
The OTA is accessible from the notification tray after unlocking the device.

Environmental Variables:
Device: Flame 3.0 (319MB)(Full Flash)
Build ID: 20150526010203
Gaia: 7cd4130d4f988562a77d126860408ada65bb95ef
Gecko: 43f2f0c506ea
Gonk: 040bb1e9ac8a5b6dd756fdd696aa37a8868b5c67
Version: 41.0a1 (3.0)
Firmware Version: v18D-1
User Agent: Mozilla/5.0 (Mobile; rv:41.0) Gecko/41.0 Firefox/41.0

Environmental Variables:
Device: Flame 2.2 (319MB)(Full Flash)
Build ID: 20150522002508
Gaia: 9acbac7e6d4a2e3913af4aa202ea403501967fcd
Gecko: a1e8f172523d
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