289541 - third state for downloads: invisible but not removed

Status: VERIFIED WONTFIX

(Toolkit :: Downloads API, enhancement)

Description

[Myk Melez [:myk] [@mykmelez]]

Currently, downloads can only be either visible or removed in the download
manager.  When visible, downloads often clutter up the interface with
information the user isn't interested in.  When removed, downloads no longer
appear in the UI and cannot be retrieved by users wanting to see what they
downloaded in the past.

It would be useful to have a third state in which downloads are invisible but
not removed.  Then the download manager (or extensions that provide alternative
interfaces to downloads) could automatically hide downloads based on some
criteria (f.e. age, or whether the user has accessed the downloaded file) while
still keeping a historical record of what was downloaded.

Comment 1

[Shawn Wilsher :sdwilsh]

We now only show the last 7 days of downloads (and the number of days is configurable).  Is this sufficient?

Comment 2

[Ed Lee :Mardak]

We'll need this extra flag because cleanup will only remove downloads from view as well as each download can be individually removed from the list. (All downloads remain in downloads.sqlite unless cleared by private browsing, etc)

Comment 3

[Ed Lee :Mardak]

Attachment: v1

This adds the DB backend changes. Yay mercurial git diffs -- tracking history across copies and being able to diff them... Too bad I commit by cvs, so the history is lost anyway. :p

Comment 4

[Ed Lee :Mardak]

Attachment: v1.1

Whoops.. I put autoResume back to 0 for the test db. Strange stuff happens when you set autoResume to 1 and init the download manager.. I suppose at least now we know autoResumed downloads actually do get autoResumed. ;)

Comment 5

[Ed Lee :Mardak]

Attachment: v8.sqlite

Comment 6

[Ed Lee :Mardak]

Attachment: v1.1, really

:( hg qrefresh sometimes takes a long time to find all the changes in the mozilla tree.

Comment 7

[Shawn Wilsher :sdwilsh]

Comment on attachment 285605 [details] [diff] [review]
v1.1, really

Two things:
1) I don't think this is necessary.  We can store the relevant data with places that we can always resume it that way.
2) you don't have the full test file in the patch

I'm inclined to WONTFIX this bug currently since we plan on getting places integration landed.

Comment 8

[Ed Lee :Mardak]

The full test file is somewhat there ;)

copy from toolkit/components/downloads/test/schema_migration/test_migration_to_8.js
copy to toolkit/components/downloads/test/schema_migration/test_migration_to_9.js

Going back to the original report, should extension writers then make use of places db instead of downloads db?

Comment 9

[Shawn Wilsher :sdwilsh]

(In reply to comment #8)
> Going back to the original report, should extension writers then make use of
> places db instead of downloads db?
Yes, I do believe so.