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
Description: 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 Prerequisite: 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 Actual: The OTA cannot be installed after dismssing th einstall screen Expected: 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(https://youtu.be/vtsve5HZcS4), 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 Result: The OTA cannot be installed after dismssing the install screen
Alison, can you take a look at this please?
blocking-b2g: --- → 2.5?
QA Whiteboard: [QAnalyst-Triage+]
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?
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. Non-Solution: 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
Setting verifyme tag to get this checked on Flame whenever the issue from comment 9 is resolved.
You need to log in before you can comment on or make changes to this bug.