430000 - Only show files that exist by default; search all downloads for search

Status: VERIFIED WONTFIX

(Toolkit :: Downloads API, defect)

Description

[Ed Lee :Mardak]

From bug 400495 comment 141:
"the download manager should auto-delete UI-items where the file has been removed or renamed, but keep the backing-store item, at least its URL and download date, in the search corpus. This would relieve my Clean Up or Clear List needs."

One way to achieve this is only showing the download items that have files that exist by default but keep the history around like normal.

However it would regress privacy bug 392097 where we used to only show 7 days of downloads by default and when users searched, a lot more downloads appeared.

Comment 1

[Ed Lee :Mardak]

Attachment: v1

1) Move clear list logic into a global function so it can be replaced easily by extensions
- Don't use nsIDM clear list because we're always showing a filtered list
- Get rid performCommand for non-item stuff
- No need to worry about performCommand calling clearList multiple times

2) Refactor download.file.exists to get rid of the oddball case with explicit {} blocks
- Reuse logic for filtering list

3) Make default empty search do "exists" search

Comment 2

[Ed Lee :Mardak]

In terms of testcases.. most tests with default lists will break because we're filtering stuff out..

Perhaps I should make a pref "download.manager.onlyShowExists" and set it to false for tests..

Comment 3

[Damian Shaw [Quan]]

I'm a little worried here about privacy concerns.

I like the idea that it will only show files that exist by default. But it needs to be made very very clear to the user that this is what is happening and how exactly you remove them from the list.

For example if the user uses the new "select all" and deletes these files, the user will expect all files from the download manager will have been cleaned up. Will this happen here?

Comment 4

[Wesley Johnston (:wesj)]

Would this just completely remove the ability to browse your download history unless you could think of a search term? Sometimes I just need to browse to find something.

At the very least, I think something like this should wait until Download browsing is available in the Library.

Comment 5

[Damian Shaw [Quan]]

Thinking about all the problems with this, the most appropriate solution seems to add a highly visible toggle (perhaps a button), that was something like "Show moved/deleted downloads".

Comment 6

[Ed Lee :Mardak]

Attachment: screenshot of v2

Downloads without their file get shown in gray.

Comment 7

[Damian Shaw [Quan]]

I quite like the idea of this patch v2 in terms of the download manager very simply expressing useful information.

However this blocks bug 400495, I assume the idea was for this bug to mitigate that bug. I can assure you that this v2 will not do so in the eyes of everyone who has argued for a clear list button to be restored on that bug. Regardless, good work, it'd be nice to have something like that for RC1 :).

Comment 8

[Ed Lee :Mardak]

Attachment: screenshot of v2 + .5 opacity

Madhava suggested changing the icon as well.. (should the icon remain 50% faded if the user has it in the selection? Currently the text switches to white like any normal selected text... but I suppose leaving it faded lets the user know the currently selected one's file is deleted.)

Comment 9

[Ed Lee :Mardak]

Attachment: v2

Changes from v1..
- add browser.download.manager.filterDeleted that defaults to true
- first show filtered results and if there's nothing, show all results
- show deleted downloads as graytext
- cache "deleted" to do above as well as not needing to check each time
- .9 -> .96 to do 25 instead of 10.. but now that I think about it, chunk size is 3.. so that's 3*10 vs 3*25... I might switch it to something smaller....
-

Comment 10

[Ed Lee :Mardak]

Oh also, if users delete stuff from the list and there's nothing left, show the deleted files.

Comment 11

[Ed Lee :Mardak]

Attachment: screenshot of v2

Default list shows files that still exist.. seems like I don't keep much other than what I download over the previous version ;)

https://build.mozilla.org/tryserver-builds/2008-04-21_10:[e-mail]/

Comment 12

[Damian Shaw [Quan]]

Testing the build you just linked to:

* Still very concerned about privacy, if an item disappears off the download manager, then the user will assume it's cleaned up. Maybe this will eventually be discovered by most users, but it'll be an unwelcome learning curve for many

* Difficult to read grayed text, at least on Windows, the Size, the URL, the download competition and all search results. I have better than normal eyesight (with my glasses on hehe) and my eyes start to strain quite a bit after only trying to read information for a little bit of time.

* First search result is impossible to read unless selecting window, result is white text with a very light brown selection

Comment 13

[Ed Lee :Mardak]

Comment on attachment 316838 [details]
screenshot of v2

Graytext is bug 427179.

Comment 14

[Damian Shaw [Quan]]

Another comment I'd like to make from testing, the general idea is to display a nice clear list. This does that right up to the point where you delete/move your last items. As a friend said testing this build out:

"clear download list = clean hdd = clean mind"

Because that's how his and a lot of other peoples thought processes worked, but the moment he cleared old downloads lying around (which this build helped him find), the whole history showed and it became an unusually long list again, making him want to clear list and remove the whole download history.

Just trying to input as much as possible to find the best solution :).

Comment 15

[Damian Shaw [Quan]]

Attachment: History item showing

Friend found a bug with this build, STR:

1) Download list only contains history items
2) You download an item that is in the history
3) You open download manager and see 2 results, the new download and the history item

Comment 16

[Brendan Eich [:brendan]]

(In reply to comment #14)
> Another comment I'd like to make from testing, the general idea is to display a
> nice clear list. This does that right up to the point where you delete/move
> your last items. As a friend said testing this build out:
> 
> "clear download list = clean hdd = clean mind"

This is important. It may be that Search should relieve us from manually cleaning up filesystem data. Just make a big pile of files and always search. That works for the web because you can't possibly clean up the web.

But one's filesystem is different in two ways: scarcity (you will run out of space or inodes if you download enough stuff including big files); cognitive model for "My stuff" that you can see in the OS filing UI.

> Because that's how his and a lot of other peoples thought processes worked, but
> the moment he cleared old downloads lying around (which this build helped him
> find), the whole history showed and it became an unusually long list again,
> making him want to clear list and remove the whole download history.
> 
> Just trying to input as much as possible to find the best solution :).

This is great input. If the user has a "spring cleaning" model (for any value of "spring") then the list going from one non-deleted item to all deleted is not good for that fresh feeling obtainable in Firefox 2.

/be

Comment 17

[Mike Connor [:mconnor]]

What's the thought process here?  Why is this better?  This means there's all sorts of invisble-unless-you-search data with privacy implications.

I'd rather just nuke the entries from the download manager if the file is gone.  The use case that this bug enables is a much better fit for the Library style of viewing/querying, and the Places DB already has that information.

Comment 18

[Brendan Eich [:brendan]]

I agree with mconnor, this bug is trying to have it both ways where the conflicts between the two ways (Search knows all; Clear cleans up) are too great. I'm sorry I suggested it over in bug 400495. Ed, thanks for exploring the idea, it helped to illuminate the issues.

/be

Comment 19

[Brendan Eich [:brendan]]

I.e., I'm fine with WONTFIX'ing this. INVALID, even. Ed?

/be

Comment 20

[Ed Lee :Mardak]

WONTFIX as is. Perhaps something more like attachment 316629 [details] of bug 429862 would be reasonable where search only looked through things listed in that view with one view being "only files that exist"