Don't use `Downloader` after the download is complete
Categories
(Toolkit :: Application Update, task, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox83 | --- | fixed |
People
(Reporter: bytesized, Assigned: bytesized)
References
Details
Attachments
(1 file)
(deleted),
text/x-phabricator-request
|
Details |
Currently, we only ever download a single update per Firefox session, but we are working on changing that (Bug 353804). One of the barriers is that we will need to create a new Downloader
instance in order to download another update. Currently, we only store a single Downloader
and we keep using it, even after the download has completed.
This means that to download another update, we either have to accommodate multiple Downloader
instances, or get rid of them when we are done with them. Logically, a Downloader
should only be needed while downloading, so the latter option seems preferable.
There are a few things that need to be done to allow this:
Downloader.patchIsStaged
needs to be refactored out ofDownloader
.- Some usages of
UpdateService._downloader
will need to be changed to ensure that they still do the right thing whenUpdateService._downloader
isn't around. I took a quick look through these, and none of them look particularly problematic. - After download is complete, we'll want to perform
UpdateService._downloader = null;
Assignee | ||
Comment 1•4 years ago
|
||
I've identified an additional change that will be required. The download listeners should no longer be stored on the Downloader
. Some of them expect to persist across multiple downloads (for example a failed partial patch download that falls back to a complete patch). That expectation would be broken if we delete the download listeners along with the Downloader
. Storing them in UpdateService
instead will ensure that these expectations continue to be met.
Assignee | ||
Comment 2•4 years ago
|
||
Comment 4•4 years ago
|
||
bugherder |
Description
•