431286 - Download instance persists in History even if cleared from download manager list

Status: RESOLVED WORKSFORME

(Toolkit :: Downloads API, defect)

Description

[Nochum Sossonko [:Natch]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9pre) Gecko/2008042806 Minefield/3.0pre

The download manager "delete from list" option doesn't clear the download from history, the download can still be found in the History even after being cleared from the download manager.

Reproducible: Always

Steps to Reproduce:
1.Download a file (I was downloading .wmv files)
2.Open the download manager, right-click on the download and select "delete from list.
3.Hit Ctrl+H to open history and search for the filename of the download
Actual Results:  
The download still remains in History.

Expected Results:  
The download should be cleared from history when cleared from the download manager.

Comment 1

[Nochum Sossonko [:Natch]]

Additionally it's interesting to note that deleting any download from history does remove it from the download manager, a little strange if the idea was to maintain separate lists.

Firefox 2 doesn't save downloads in the history, so this bug exists only in 3.

Comment 2

[Stephen Donner [:stephend] Not actively reading bugmail]

I can confirm the behavior with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042904 Minefield/3.0pre; if I "Clear Private Data", though, and include "Browsing History", the .dmg entry goes away.

Is this expected behavior or not?  (Sad and shameful that I don't know!)

Comment 3

[Shawn Wilsher :sdwilsh]

(In reply to comment #1)
> Firefox 2 doesn't save downloads in the history, so this bug exists only in 3.
Actually, it did, just not as consistently as we do now.



(In reply to comment #2)
> Is this expected behavior or not?  (Sad and shameful that I don't know!)
Since we landed the expire stuff, we will remove it from the list when it's removed from history.

I'm not sure if we want to remove it from history though when you remove it from the list.  Requesting blocking to get an opinion from drivers (note, this wouldn't be too hard to do).

Comment 4

[Mike Beltzner [:beltzner, not reading bugmail]]

This doesn't block Firefox 3, fwiw. If someone wants to clear their history, they are still more than able to do that.

I'm waffling on whether or not I think that this is the desired behaviour. Deleting a download from the list does imply that you no longer want that download in the list, but does it imply that you don't want to be able to revisit the site from which that file was downloaded? Right now the object in the DM represents a "download", so information about where it came from, and where it exists on the filesystem. I'm not sure that I ever would have expected that to be stored in history in the first place, to be honest.

Madhava/Connor: thoughts?

Comment 5

[Nochum Sossonko [:Natch]]

I'd just like to present a few thoughts on this matter that can perhaps shed light on the validity of this request:

In a way the idea of not removing the entry from history does fit in with the whole inbox idea of the download manager mentioned in the bug about the "clear list" button (can't find it at the moment), however if this was indeed the intent of the download manager, the name is a bit misleading as the downloads aren't entirely "managed" at the dm. Consequently, if we were to compare the dm to an inbox, and the "remove entry" as archiving (say in gmail), then the true download list is really to be found in History (which would be similar to "all mail" in google). If so the search bar in the dm is not a very thorough tool and certainly not as important as it was made out to be in the aforementioned bug (and maybe a bit superfluous).

Finally, if the inbox approach is indeed correct then the search should be performed similar to gmails search (although there is no real connection, just bringing it here to compare ideologies on usefulness) which, even when in the inbox, does a full "all mail" search.

Again if this approach is wrong entirely, I fail to understand why one would have to delete any download he doesn't want to keep, say for privacy reasons, twice, when most would think that once deleted from the dm it shouldn't be findable anymore.

Comment 6

[Mike Connor [:mconnor]]

(In reply to comment #5)
> Again if this approach is wrong entirely, I fail to understand why one would
> have to delete any download he doesn't want to keep, say for privacy reasons,
> twice, when most would think that once deleted from the dm it shouldn't be
> findable anymore.

Well, the counter there is that in most cases, if you don't clear the corresponding history (pages link to downloads, etc), "privacy" is usually a falsehood.  The page that linked to the download is likely still there, etc.  Its just less obvious.  It doesnt delete the file when you clear the entry, so that's still there too.  At best, its a false sense of privacy, like putting a cheap bike chain on in Toronto is a false sense of security.

Of course, if we auto-prune moved downloads (in a more DM-as-set-of-downloaded-files approach) then this bug gets even more complicated.  The question that needs to be asked is "what is the UI we want."  If I were designing from scratch, I would make the DM directly interact with files in most cases (delete == delete) and have the history info as part of the overall history views.  Clear List would be akin to Remove All Files in transmission, so if you wanted to dump all of the downloaded files, you could.

Really, we can probably still get there, but we'll need some intermediate steps first.

Comment 7

[Nochum Sossonko [:Natch]]

(In reply to comment #6)
>Well, the counter there is that in most cases, if you don't clear the
>corresponding history (pages link to downloads, etc), "privacy" is usually a
>falsehood.  The page that linked to the download is likely still there, etc. 
>Its just less obvious.

I'm sorry if I wasn't perfectly clear before, but what I intended before was that say I download a file from an ftp site, in which I include a username and password in the file download link as a means of gaining access to the site (I've seen this method used on quite a few sites), then all I'm worried about is the download URL alone, which I want to get rid of so as not to give out the information to any prying eyes.

Comment 8

[Susan Thomas]

I performed 2 d/ls, cleared the list and then d/l'd a 3rd file.  The 3rd file did not then appear in the d/l list but the 1st file d/l'd and previously cleared did appear -- I confirmed that the 3rd file was actually d/l'd.

Tried to replicate -- several more file d/l'd do not appear in list although I confirmed they were d/l'd, but now neither does any prior file appear in the list.

I am using: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008051206 Firefox/3.0

Comment 9

[Nochum Sossonko [:Natch]]

Current trunk builds aren't recording downloads in the history, so this is pretty much WFM

Comment 10

[Shawn Wilsher :sdwilsh]

(In reply to comment #9)
> Current trunk builds aren't recording downloads in the history, so this is
> pretty much WFM
Uh, they should be.  In fact, I'm pretty sure we have tests that verify that it still does...

Comment 11

[Nochum Sossonko [:Natch]]

(In reply to comment #10)
> Uh, they should be.  In fact, I'm pretty sure we have tests that verify that it
> still does...

See bug 463863.

Comment 12

[Nochum Sossonko [:Natch]]

See bug 465995 and bug 479666 which are consequences of the mixture of download and history approach.

/me checks IE Chrome Opera and Safari for parity...

Comment 13

[klonos]

verifying this one still in: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090426 Minefield/3.6a1pre (.NET CLR 3.5.30729) ID:20090426044401

in: Mozilla/5.0 (Windows; U; Windows NT 6.0; el; rv:1.9.1b3) Gecko/20090305 Firefox/3.1b3 (.NET CLR 3.5.30729) ID:20090305152042

and in: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.9) Gecko/2009042113 Ubuntu/8.10 (intrepid) Firefox/3.0.9 - Build ID: 2009032711

Comment 14

[Nochum Sossonko [:Natch]]

Would be nice to get some input from UX/drivers on the status of this bug. I believe this is wontfix...

Comment 15

[Shawn Wilsher :sdwilsh]

No, I think we should probably fix this.  Just need to remove the page from history in these places:
nsDownloadManager::RemoveDownload
nsDownloadManager::RemoveDownloadsForURI

And then clear all downloads from history when nsDownloadManager::CleanUp is called.

Comment 16

[Ronny Perinke]

Attachment: remove pages from browser history if removed from download manager

Remove pages from browser history in nsDownloadManager::RemoveDownload and nsDownloadManager::CleanUp as mentioned in comment #15 plus 
nsDownloadManager::RemoveDownloadsByTimeframe. nsDownloadManager::RemoveDownloadsForURI calls nsDownloadManager::RemoveDownload so the actual removal happens there.

I had to extend the nsIBrowserHistory interface with a new non-scriptable variant of the removePages method that accepts a nsTArray<nsIURI> instead of a double pointer to a nsIURI-array, because I did not new a better way to be honest. I tried to use nsTArray::Elements() but that resulted in compiler complains about nsIURI being an abstract class (error C2259).

Comment 17

[Marco Bonardo [:mak]]

Comment on attachment 625138 [details] [diff] [review]
remove pages from browser history if removed from download manager

Review of attachment 625138 [details] [diff] [review]:
-----------------------------------------------------------------

I don't like the addition to nsIBrowserHistory at all, and this will negatively impact the new panel in Firefox where downloads and history are properly separated concepts.
I still think this is a wontfix, but want to think about it.

Comment 18

[Nochum Sossonko [:Natch]]

Is this still an issue with the new DL panel?

Comment 19

[Nochum Sossonko [:Natch]]

WFM with new integration directly into Library.