Closed Bug 827090 Opened 12 years ago Closed 7 years ago

Persist that a system update is happening to be able to resume it after a reboot

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:-)

RESOLVED WONTFIX
blocking-basecamp -

People

(Reporter: julienw, Unassigned)

Details

STR: - get a system update notification (you get one when you flash a custom build) - reboot the phone -> the notification is not shown unless the user force checks or wait for whatever delay is configured (default is 1 day) From Bug 819548 comment 25: We could have the code which posts an update notification set a setting, which gets cleared once the user starts the download. Then the startup code could check that settings and set the same forceCheck flag (in the same place we check the interrupted download). If the phone doesn't reboot, then the extra setting doesn't do anything, but if it reboots, then its the same thing as the user choosing checkForUpdates if they've been notitifed of an update. I'd say this is even not B2G-specific.
blocking-basecamp: --- → ?
Per triage, the default delay is ok - not blocking.
blocking-basecamp: ? → -
We did implement a workaround in Gaia in Bug 819548. Etienne and I think that this would be better in gecko though, so I'm changing the title to reflect this. This is also related to bug 813770 which does a lot of things in gecko already to not make the update restart automatically.
Summary: we don't get the system update notification automatically after a reboot → Persist that a system update is happening to be able to resume it after a reboot
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.