Closed Bug 1000552 Opened 8 years ago Closed 8 years ago

about:downloads content no longer persists across restarts

Categories

(Firefox for Android Graveyard :: Download Manager, defect)

ARM
Android
defect
Not set
normal

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)

2 or three weeks ago in Android nightlies downloads stopped persisting across browser restarts.  Is this an intentional behavior change?
No.
Blocks: 901360
tracking-fennec: --- → ?
Keywords: reproducible
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
tracking-fennec: ? → 31+
Severity: normal → major
Severity: major → normal
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.
Attached patch downloadPersistSplinter Review
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 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)
> 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....
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?
(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.
(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.
Another good idea here would be to check for the file still existing before persisting the about:downloads entry.
Assignee: nobody → wjohnston
Status: NEW → ASSIGNED
tracking-fennec: 31+ → ---
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: 8 years ago
Resolution: --- → FIXED
(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.
As soon as those patches are up and ready, I'd be happy to land it again.
Assignee: nobody → wjohnston
Target Milestone: --- → Firefox 32
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).
Status: RESOLVED → VERIFIED
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.