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)
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.
Reporter | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 1•12 years ago
|
||
Per triage, the default delay is ok - not blocking.
blocking-basecamp: ? → -
Reporter | ||
Comment 2•12 years ago
|
||
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
Comment 3•7 years ago
|
||
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.
Description
•