Closed Bug 1219471 Opened 4 years ago Closed 4 years ago

User will be unable to install the OTA after dismissing install screen via home button


(Firefox OS Graveyard :: Gaia::System::Status bar, Utility tray, Notification, defect, P2)

Gonk (Firefox OS)


(blocking-b2g:2.5+, b2g-v2.2 wontfix, b2g-master verified)

blocking-b2g 2.5+
Tracking Status
b2g-v2.2 --- wontfix
b2g-master --- verified


(Reporter: AdamA, Assigned: mcav)




(Keywords: verifyme, Whiteboard: [2.5-Daily-Testing][Spark][systemsfe])


(2 files)

Attached file logcat
If the user is in an app while an OTA is uncompressing and receives the install screen they can press the home button to dismiss the install screen. If the install screen is dismissed this way theyy will not be able to install the OTA manually. Opening the notification center will show uncompressing on the OTA section

An OTA is available.

Repro Steps:
1) Update a Aries to 20151027122943
2) Start downloading the OTA in the notification center
3) Open an app and wait for the OTA to finish uncompressing
4) Press the home button as the install confirmation screen appears
5) Open notification center
6) Observe inability to install OTA

The OTA cannot be installed after dismssing th einstall screen

It is expected that the user is able to install the OTA

Environmental Variables:
Device: Aries 2.5 [Full Flash]
Build ID: 20151027122943
Gaia: b6ede3d0fdec5fc922e9ca3401e60db461bf705c
Gecko: 9a8f2342fb3116d23989087e026448d38a3768c5
Gonk: 2916e2368074b5383c80bf5a0fba3fc83ba310bd
Version: 44.0a1 (2.5)
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Repro frequency: 10/10
See attached: video clip(, logcat
This issue DOES occur on Flame 2.2 and Flame 2.5.

Environmental Variables:
Device: Flame 2.5 [Full Flash]
BuildID: 20151028030421
Gaia: 2e89362de40a6c9c36525d36317fa1ae8e67e143
Gecko: fc706d376f0658e560a59c3dd520437b18e8c4a4
Gonk: 205ac4204bbbb2098a8046444acba551ba5dc75a
Version: 44.0a1 (2.5) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:44.0) Gecko/44.0 Firefox/44.0

Device: Flame 2.2 [Full Flash]
BuildID: 20151028032502
Gaia: 885647d92208fb67574ced44004ab2f29d23cb45
Gecko: 05144e035522
Gonk: bd9cb3af2a0354577a6903917bc826489050b40d
Version: 37.0 (2.2) 
Firmware Version: v18D
User Agent: Mozilla/5.0 (Mobile; rv:37.0) Gecko/37.0 Firefox/37.0

The OTA cannot be installed after dismssing the install screen
Flags: needinfo?(ktucker)
Alison, can you take a look at this please?
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage+]
Flags: needinfo?(ktucker)
Whiteboard: [2.5-Daily-Testing][Spark] → [2.5-Daily-Testing][Spark][systemsfe]
Can we get another logcat here?
Ugh that sounds bad. Marcus, can you help out here?
Flags: needinfo?(m)
Assignee: nobody → m
Flags: needinfo?(m)
blocking-b2g: 2.5? → 2.5+
Priority: -- → P2
Comment on attachment 8680840 [details] [review]
[gaia] mcav:updatable > mozilla-b2g:master

Root Cause:

Nothing told UpdateManager to remove systemUpdatable from the downloads queue. (One would think that `UpdateManager.downloaded(updatable)` would do that, but it doesn't.) So UpdateManager would just perpetually show the update as "Uncompressing", and per update_manager.js:279, it ignores clicks on the notification when it thinks it's uncompressing.


Gregor suggested that we should not prohibit users from aborting the dialog, which is fortunate, because 'hideCustomDialog' doesn't actually invoke the "cancel" listener. It really should, but making that change system-wide would be too risky. We should try to address that in the future; dialogs can go away without being actioned, and there are likely other places where we'll run into similar problems as a result.

Proposed Solution:

This patch calls UpdateManager.removeFromDownloadsQueue(systemUpdatable) _before_ prompting the user to install; we previously did this in response to declineInstall(). Logically, we want to remove it from the downloads queue regardless, as soon as the download has finished.

With this patch, the user can re-tap on the "System Update Available... tap for more info". Ideally, we'd say "System Update Downloaded... tap to install" and skip them past the download stage, but that's not implemented. Instead, they must click "download" (which happens instantaneously because it was already downloaded) and then they get the apply prompt again. Since we're short on time, a conservative solution seemed best, rather than trying to fiddle with more logic to avoid that extra click.

I've tested this with an OTA, and updated the unit test to match the new behavior.
Attachment #8680840 - Flags: review?(mhenretty)
Comment on attachment 8680840 [details] [review]
[gaia] mcav:updatable > mozilla-b2g:master

Good investigation and solution. I agree with you that `UpdateManager.downloaded(updatable)` should just call `removeFromDownloadsQueue`, but for 2.5 your patch has a smaller footprint.

One other weird thing is that if you are on the homescreen when the install dialog appears, pushing the home button does nothing. It's only when you are in an app that the home button closes the dialog.

In any case, your patch makes it so that pushing the home button essentially does the same thing as hitting the "Later" button, so r=me.

I'm going to merge this now so it makes it into Friday's QA build.
Attachment #8680840 - Flags: review?(mhenretty) → review+
This issue is verified as fixed in Aries central. Following STR, OTA install dialog can be brought up after tapping on OTA in utility tray.

We are currently unable verify this on Flame because it requires users to go to v18D nightly v4 base image per every OTA update, and that base image does not contain this fix. We don't know what the OTA channel is for Aries 2.5 so unable to verify Aries for 2.5 either.

Verified fixed on this build:
Device: Aries 2.6 Master
BuildID: 20151125131311
Gaia: 9eca89f04628c99226e0d18c15d5ae11b71af0cf
Gecko: 1835baed2a38429a3cc301d21778a113d3a9e7d8
Gonk: a19052e4389c3ae2d8fc3e7a74a475401baacc56
Version: 45.0a1 (2.6) 
Firmware Version: D5803_23.1.A.1.28_NCB.ftf
User Agent: Mozilla/5.0 (Mobile; rv:45.0) Gecko/45.0 Firefox/45.0
Flags: needinfo?(jmercado)
Setting verifyme tag to get this checked on Flame whenever the issue from comment 9 is resolved.
Flags: needinfo?(jmercado)
Keywords: verifyme
You need to log in before you can comment on or make changes to this bug.