Closed
Bug 1000552
Opened 9 years ago
Closed 9 years ago
about:downloads content no longer persists across restarts
Categories
(Firefox for Android Graveyard :: Download Manager, defect)
Tracking
(firefox30 unaffected, firefox31 verified, firefox32 verified)
VERIFIED
FIXED
Firefox 32
Tracking | Status | |
---|---|---|
firefox30 | --- | unaffected |
firefox31 | --- | verified |
firefox32 | --- | verified |
People
(Reporter: wgianopoulos, Assigned: wesj)
References
Details
(Keywords: regression, reproducible)
Attachments
(1 file)
1.05 KB,
patch
|
Details | Diff | Splinter Review |
2 or three weeks ago in Android nightlies downloads stopped persisting across browser restarts. Is this an intentional behavior change?
Comment 1•9 years ago
|
||
No.
Updated•9 years ago
|
status-firefox30:
--- → unaffected
Comment 2•9 years ago
|
||
The fix probably just involves tweaking shouldPersistDownload based on what you need: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadIntegration.jsm#305
Updated•9 years ago
|
tracking-fennec: ? → 31+
Updated•9 years ago
|
Severity: normal → major
Updated•9 years ago
|
Severity: major → normal
Comment 3•9 years ago
|
||
The downloaded files are not accessible from the device anymore once their reference is removed from the Firefox download manager. That is why I think that this is a major problem.
Assignee | ||
Comment 5•9 years ago
|
||
Agreed. Need to test this, so just setting feedback first. This (I think) persists everything forever. That's consistent with our old behavior and I think is probably our best first start. I wonder, do you know if we need to migrate the old download data into the new files as well paolo?
Attachment #8414519 -
Flags: feedback?(paolo.mozmail)
Comment 6•9 years ago
|
||
Comment on attachment 8414519 [details] [diff] [review] downloadPersist (In reply to Wesley Johnston (:wesj) from comment #5) > Agreed. Need to test this, so just setting feedback first. This (I think) > persists everything forever. That's consistent with our old behavior and I > think is probably our best first start. The only thing to consider is that performance might be affected if the list becomes too long. I'm not familiar with the UI on Android, but on Desktop the download history tended to stay in place forever, as most users never cleared it. > I wonder, do you know if we need to migrate the old download data into the > new files as well paolo? Good point, you'll need to update the import code to take existing completed downloads into account on Android: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadImport.jsm#120 This code runs only once, when the new API is initialized for the first time. You'll need to reset the "browser.download.importedFromSqlite" preference if testing again on the same profile. Last thing, what is the difference between ANDROID and MOZ_WIDGET_ANDROID? I always forget, and keep asking hoping that someone will move this information to a wiki page sooner or later :-)
Attachment #8414519 -
Flags: feedback?(paolo.mozmail)
Assignee | ||
Comment 7•9 years ago
|
||
> Last thing, what is the difference between ANDROID and MOZ_WIDGET_ANDROID? I
> always forget, and keep asking hoping that someone will move this
> information to a wiki page sooner or later :-)
Heh. Since b2g is based on the Android kernel, ANDROID will work for it as well. MOZ_WIDGET_ANDROID is FFAndroid only. I can put that on a wiki, but not sure what page that is....
Comment 8•9 years ago
|
||
FYI, notifications will come back after a restart. I do have a WIP patch that adds tracking to remember if a notification is dismissed. Should I attach it?
Comment 9•9 years ago
|
||
(In reply to James Gilbertson from comment #8) > FYI, notifications will come back after a restart. I do have a WIP patch > that adds tracking to remember if a notification is dismissed. Should I > attach it? I'd be interested in the approach, though this might be eventually solved in a separate bug. Note that if this happens only because of onDownloadAdded being triggered for existing downloads, maybe you can also choose to ignore onDownloadAdded notifications until the promise returned by addView is resolved.
Assignee | ||
Comment 10•9 years ago
|
||
(In reply to James Gilbertson from comment #8) > FYI, notifications will come back after a restart. I do have a WIP patch > that adds tracking to remember if a notification is dismissed. Should I > attach it? I finally tested this today and saw that :) I'd love to see that patch too.
Reporter | ||
Comment 11•9 years ago
|
||
Another good idea here would be to check for the file still existing before persisting the about:downloads entry.
Updated•9 years ago
|
Assignee: nobody → wjohnston
Status: NEW → ASSIGNED
Updated•9 years ago
|
tracking-fennec: 31+ → ---
Assignee | ||
Comment 12•9 years ago
|
||
Fixed by backout. Tracking for our next pass at Downloads.jsm, but these are cluttering up my list of bugs.
Assignee: wjohnston → nobody
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Comment 13•9 years ago
|
||
(In reply to Wesley Johnston (:wesj) from comment #12) > Fixed by backout. Tracking for our next pass at Downloads.jsm, but these are > cluttering up my list of bugs. We've made substantial progress on WebAppRT, our last blocker, when do you think this next pass on Android will take place? As I understand it, all the regressions have a clear and simple solution.
Assignee | ||
Comment 14•9 years ago
|
||
As soon as those patches are up and ready, I'd be happy to land it again.
Updated•9 years ago
|
Assignee: nobody → wjohnston
Target Milestone: --- → Firefox 32
Comment 15•9 years ago
|
||
The downloads from about:downloads persist across browser restarts. Verified as fixed in builds: - 32.0a2 (2014-06-11); - 31 Beta 1; Device: Google Nexus 7 (Android 4.4.2).
Updated•2 years ago
|
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•