User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:0.9.9+) Gecko/20020320 BuildID: 2002032003 There should be some method of having files that have been successfully downloaded automatically removed from the Download Manager list. If you aren't interested in a history of what you've received, you have to, currently, manually delete every download entry. Is this not something that other DMs have as a preference? (I've never really used any all that much, and only use the Mozilla DM because it's now built-in.) Actual Results: Successfully downloaded files appear in the Download Manager list. Expected Results: Entries for downloaded files should be removed once successfully retrieved. BTW: I would have used the bug helper to submit this, but I could not find the componenent "Download Manager" in its dropdown list. It *IS* available in the "Enter Bug" list so I used it instead.

A pref for the downloads pref panel?: [X] Keep completed and cancelled downloads in the download manager

My experience is such that I usually like to keep the list of files I directly initiated in a download manager window so that I can verify completion, launch, or reschedule them. I'd also like to watch the other transfers (e.g. images, CSS, gopher, news, etc.) so that I can monitor number of connections and speeds. For those types of transfers, the browser handles completion and launch directly, so I'm less interested in watching the results. Is it feasible to implement a solution where only these "user-initiated transfers" are caught? My rule-of-thumb for defining these "user-initiated transfers" is any transfer that would trigger the old-school dialogs. Those are few enough to be tractable, whereas including all visited HTTP links would not. Even so, there are probably people that want no completed transfers to remain, and there could easily be a pref to allow that.

I expect very few browser users are interested in tracking completed downloads past the current session. Our suddenly keeping track of them in a window that doesn't appear by default may be an unwelcome surprise. Perhaps these should be migrated to a new history group upon successful completion?

FWIW: I don't agree with changing the severity of this bug to "enhancement". I suspect that far more people would prefer to not have the download manager keep a history of downloads between sessions. As such, the "normal" behaviour should be to remove such history upon exit. The *retention* of download history of downloads should be an enhancement to the normal operation of not keeping them. I see this bug as an actual bug to be fixed rather than an "added feature". (Retention of download history should be the added feature.)

The current behavior is as intended, not a defect; thus changing it would be an enhancement, not a bugfix.

That makes no sense. It's as intended because that's the way it currently is? Any number of bugs are discussed and resolved one way or the other. Not everything that is "not broken" is "as intended". New Tabs and New Windows are functional, yet there is discussion of what order they should be in - and nobody is claiming that the current order is "as intended" and that changing the order to something different should only be an enhancement...

Uh, no, that's not what I said. If you must paraphrase, then how about "It is the way it is because that's what was intended." In the absence of a spec, then 'the way it is' might be a substitute, but we were following a spec in this case. This is a waste of time arguing over such semantics anyway, think of it any way you want.

Based on insistence that this is an enhancement, rather than a requested change of behaviour, I have modified the bug summary to better reflect said severity.

*** Bug 141336 has been marked as a duplicate of this bug. ***

I'd like to see an accompaniment to that preference, for "Clear download manager list on exit" or similar.

I have opened bug 146059 - Need prefs to control download history. If that bug is fixed it will address the concerns here. Note that it is not a duplicate. I think we should be able to have comlete control over the download history, not just a choice to remove completed downloads from the list. Feel free to post other suggestions for the "Download History" section of the download manager pref panel there.

cross-bug note: bug 136054, bug 132755, and bug 141794 all specify different ways to expire entries from the download history. To avoid duplication of effort, work on any one bug should be coordinated (if not combined) with work on the others.

Suggested UI: +--------------------------------------------------------------------+ | Remove completed and cancelled downloads in the download manager: | | | | ( ) Never | | | | ( ) Immediately | | ___________ | | (o) After [ 20 ] [ minutes \/] | | |-----------| | +----------------------| minutes |---------------------------------+ | hours | | days | | weeks | | months | | years | +-----------+

I don't like the 'delete after xx minutes' idea, but would like to have some 'delete after this session' option (see comment #3)

+--------------------------------------------------------------------+ | Remove completed and cancelled downloads in the download manager: | | | | ( ) Never | | | | ( ) Immediately [x] Notify me of a completed download | | | | ( ) after each session | | | | ( ) Keep the last [ 10 ] | | ___________ | | (o) After [ 3 ] [ days \/] | | |-----------| | +----------------------| minutes |---------------------------------+ | hours | | days | | weeks | | months | | years | +-----------+

How about a check box for "Close Download Manager when all downloads complete"?

This seems unnecessarily complex and confusing. Surely the vast majority of users would be satisfied with either no pref or the one described in comment #1; certainly nothing more complicated than what has sufficed for history.

I like comment #13, but without the choice of minutes, hours, etc. Only days. Perhaps the 'current session' choice from #15 would also be good. There may be other considerations for the UI, such as notification of completed downloads. This could be particularly useful when we are able to choose a 'silent' download. If we are going to have a download manager in the product it should be a reasonable and desirable substitute for the external managers which are available or it's a waste of time.

I don't buy that. A built-in download manager should not attempt to have everything that a stand-alone, dedicated product has, if only because the target users of the individual products are so different. Hundreds of millions of people use browsers,but I'd be surprised if even hundreds of thousands use separate DL mgrs. In pleasing the 0.1%, you have to be careful not to adversely affect the 99.9%.

I agree with comment 18. By introducing a "download manager" in the first place you are daring people to criticise it for it's lack of functionality compared to 3rd party utilities. Mozilla is already taking on too much by integrating an email client, and an HTML editor, and, etc., etc. It's already becoming an "I can do everything" application, rather than just a browser. Introducing a "very limited" download manager just adds to this. I, too, think that it should be removed altogether and reverted back to the simple download progress window (which was never really broken in the first place). However, that not being an option, if Netscape insists on its presence, there should be a committment to make it at least a "light" version of the 3rd party utilities out there, rather than just an annoyance.

This does not have to be an 'all or nothing' choice, nor is it Netscape vs Mozilla. There is an appropriate level of functionality that could hit the sweet spot for many users here, and the intention is that it is something similar to what can be found in other *popular* browsers. There is no need to try to obviate stand-alone DL Mgrs, they should still present a viable choice for the tiny minority of users who want such functionality.

As to the agrguement of "Full featured" vs. "For the masses", how about having a default action (ie: remove completed files from list, close when completed download, don't download files while manager is closed) that is what the masses expect when they click on a file. Basic functionality should be transparent to occasional users. Let the advanced users mess around with the options.

Of course you have default behavior, but that is no reason to complicate and bloat the program with features few if any people will ever need. Even advanced users are slowed down by creeping featuritis, and every extra codepath increases the chance of instability. This extra stuff is not free. Simpler is better.

Peter: It seems to me that you're the only one arguing your position. Every other comment here is calling for (what we consider to be) a suffucient number of features. Is there anybody else following this bug who agrees with Peter? (I'm not actually sure what his point is, to tell the truth.) What exactly are you arguing for? Can you give a synopsis of what you think the download manager SHOULD be doing? Hopefully, it's not just what it's doing now...

Personally, I don't mind our download manager having lots of features. I do, however, mind it having stupid prefs. Here I don't see much need for more than: [X] Keep completed and cancelled downloads in the download manager

I prefer Ian Hickson's suggestion. I would also prefer to have this preference unchecked by default. Most users wouldn't want to keep a track of downloads between sessions.

Jason, I'm resisting the endless accretion of prefs and features that appeal only to a tiny minority, at the expense of most users. We are not building a browser for a few thousand contributors, but rather for the masses. I think I've made my point here, and I think it is important for someone to push back, or else only the contributor's personal preferences will be represented. I respect your disagreeing with me, but I don't know what I've said that you don't understand. We have had a spec for this feature for nearly a year, that we agreed to implement. Some changes were necessary, and even some additions, but to go from zero prefs to filling an entire panel suggests this feature would become a stand-alone app, or even a platform in itself if some folks had their way. That's fine, but it isn't the feature we need here.

I suspect one reason people are asking for this is that when download manager comes up on a download, it's too stupid to automatically scroll to currently active downloads (preferably the one just requested). I couldn't actually find this bug in bugzilla on a quick search, but it's a major usability problem with download mgr imho. I think this is why people are asking for pref panels from hell (aka comment 15).

I agree that lack of scrolling to the active panel is a usability problem, and should be a requirement. Please file a bug on that.

I agree that there shouldn't be an endless series of prefs in the download manager. In fact this bug, which I filed myself, is only about one. (Not keeping successful downloads). If that's all that comes out of this I'll be happy. Having said that, however, I'm not sure I agree that there shouldn't be some limited additional functionality. A slightly expanded version of always/never deleting the downloads doesn't seem that outrageous to me - although I would certainly cut back the example in comment 15 to the following, since it's (more than) a bit complex as suggested: Keep completed downloads: ( ) Forever ( ) For [ ] Days ( ) Never This offers the ability for dating which, based on discussion here, seems to be a desired addition, but also doesn't offer up an unwieldy number of increased options. It also has the advantage that at the back end there is only a single numerical variable: the number of days to keep the downloads (with 0 for never and -1 for always). It also avoids the "pref panels from hell" syndrome <grin>, as mentioned in comment 28. As for the note in comment 16, I believe that that should be sufficiently covered by bug 132440, which would let people (again) have a UI for choosing to see the download manager window in the first place or not (even though you can view it anytime you want via the Tools menu). I'm not of the opinion that that many people would want to have the download *manager* pop up during a download then disappear again when it was done. If all somebody wants is to see the download *status*, then user_pref("browser.downloadmanager.behavior", 1); sufficiently covers that desire - it just needs to be exposed again in the UI.

How about: ( ) Keep completed downloads: For only [ ] Days

Even better!

trudelle, in fact it does already exist after a better search: bug 141410 I still don't understand what's wrong with making this hang off the pref the user has set for URL history (i.e. expanding the meaning of that pref), as discussed on IRC. Then this bug can simply be about comment 1 again (which is a good idea IMO, independent of any others).

Leveraging the history UI sounds good to me, but I'm not sure about hanging this off of history.

I'm not sure I'm following the consensus here properly (if there is any), but it seems to be pointing in the direction of just 2 main prefs: [x] Use download manager (rather than ...) Keep completed (or stopped) downloads: (o) Forever ( ) For [ ] Days ( ) Never That suit anyone at all? Those aren't presented very clearly there, but I don't know what the proper format is for this type of thing.

One more suggestion: ( ) Keep completed downloads: ( ) Remove after [ ] days

If we leverage known usability of the History pref, it would be more like this: [X] Use Download Manager to track download progress. Remember downloads for [####] days We might also consider a (Clear Downloads) button, as in History. IMO, if they aren't using the download manager, we shouldn't be tracking them, hence Remember should be disabled when Use is disabled. I think that 4 digits is way overkill for the duration, but that's what is in History. Tooltips could add some further explanation. cc UE, Doc specialists for input.

> [x] Use download manager (rather than ...) The pref above is covered by bug 132440 (unless I'm missing something), and doesn't need to be discussed here. (Does it?)

In comment #37 it isn't clear how to keep the downloads forever. Comment #36 provides for this.

Let me make it clear: you don't. If anyone really has any need to keep track of downloads longer than 9,999 days, well then they are just SOL.

> Let me make it clear: you don't. If anyone really has any need > to keep track of downloads longer than 9,999 days, well then > they are just SOL. Whoa! Things were going reasonably up to now. I think that there *should* be an explicit "never delete" possibility - even if it's "functionally" no different from 9,999 days. Not providing that is just strange. I'm also not sure where the autocratic attitude is coming from - if we aren't supposed to discuss and weigh everybody's input then it shouldn't be an open forum in the first place. Further, I think that moving the ability to keep for X days to the URL history component is out of scope of this particular bug. If you want to move it there then fine, but I would take it up somewhere else. I believe that the only discussion HERE should be of of "Download Manager" UI prefs. (Assuming that anything more than just the initial bug report is to be discussed.)

What's autocratic? I'm weighing, I'm discussing, and I couldn't dictate what goes in if I wanted to (which I don't). Don't I get to put forth my opinion? In any case, I'm just clarifying my agreement with the input of others who proposed that we should leverage the History UI for a similar situation, which as been tested by tens of millions of users over the last several years. I see no need to complicate the UI for this by offering more ways of accomplishing essentially the same result, just because you think it would be strange not to. We have no data that there is any usability problem with the History-style UI, nor any data that target users need more than the simple 'keep for x days' control. Do the math, that is more than 27 years. Do you really think anyone is going to be using the same profile 27 years from now?

We REALLY need the option of immediately removing downloads from the list as well. I don't want to wait 1 day (which seems to be the shortest period with the current suggestion) for the downloads to fall off the list...

This is also the case for a tiny number of people using history. You can set zero days, or delete them as you go, or just use the old progress dialogs, which have that exact behavior. If we tried to account optimally for every possible scenario, we would inevitably make them all more complicated than they need to be. The best strategy is to optimize for the common cases, and only accomodate the edge cases when it can be done without affecting the others. Jason: I think I understand how you were sensing 'attitude' reading comment #40, but I assure you that I didn't intend it in the sense of 'do it my way or else', but rather that *if* we implemented the UI as in comment #37, then *users* who wanted download records kept for 28 years or more would be SOL.

I think it may be a mistake to use the history UI. History implies that you want to keep track of where you were. That may not be true in Download Manager. IMHO, from a UI point of view, comment 36 seems to be the most clean and simple to understand for the end user.

Peter: My apologies if I misinterpreted comment 40. It just sounded at the time, to me, a little confrontational. The reason I don't like having this in the history UI is that if bug 132440 is resolved, there will be a Download Manager pref UI in place. It seems logical that any further prefs for controlling DM behaviour should go there, rather than anywhere else. (Otherwise, prefs for the same component end up being in different places, which only leads to confusion.) *Only* if bug 132440 is closed without a fix might, theoretically, the pref for download dating be moved to somewhere such as history. As for comments about why you can't keep something forever because of a 27 year limit, I'm a little unclear. The same principle I brought up in comment 30 should apply here. Just set the value to "-1" if you want it to never expire, or to "0" if you don't want it ever kept. Is that not technically possible for some reason? All of that having been said, I'm also still in favour of the solution in comment 36.

>> We REALLY need the option of immediately removing downloads from >> the list > You can set zero days, or delete them as you go, or just use the old > progress dialogs FYI: Using the old progress dialogs (which I do since I don't like seeing the Download Manager in the first place) does not, for me anyway, result in having downloads removed from the list automatically. When I invoke the DM manually, I still see all of my downloads sitting there. If there is some way of getting them removed in combination with user_pref("browser.downloadmanager.behavior", 1); please let me know.

+--------------+--------------------------------+------------------------------+ |\ Proposal | Comment 36 | Comment 37 | + \ +--------------------------------+------------------------------+ | --- | | | | \ | ( ) Keep completed downloads: | ( ) Use Download Manager to | | -- | | track download progress. | | \ | | | | --- | ( ) Remove after | Remember downloads | | Task \ | [ ] days | for [ ] days | | \| | | +--------------+--------------------------------+------------------------------+ | Don't use | Uncheck ( ) Keep completed ... | Uncheck ( ) Use Download ... | | Download | | | | Manager | | | +--------------+--------------------------------+------------------------------+ | Use Manager | Check (O) Keep completed ... | Check (O) Use Download ... | | Don't List | Check (O) Remove after | Set [ 0] days | | Downloads | Set [ 0] days | | +--------------+--------------------------------+------------------------------+ | Use Manager | Check (O) Keep completed ... | Check (O) Use Download ... | | List Dwnloads| Check (O) Remove after | Set [xxxx] days | | for xxxx days| Set [xxxx] days | | +--------------+--------------------------------+------------------------------+ | Use Manager | Check (O) Keep completed ... | Check (O) Use Download ... | | List Dwnloads| Uncheck ( ) Remove after | Set [9999] days | | forever/27yrs| | | +--------------+--------------------------------+------------------------------+ Comment 36 and comment 37 are essentially the same. However, it seems to me that comment 37's proposal requires fewer steps to use and is a bit more straightforward. Using comment 37's proposal means that we can just borrow the logic from history. Users who know how to use one feature can take their knowledge over to the other. Should we really write new code and force new logic onto the user just so a few can keep their downloads listed longer than 27 years? IMHO, no!

> I'm also not sure where the autocratic attitude is coming from - if we aren't > supposed to discuss and weigh everybody's input then it shouldn't be an open > forum in the first place. That doesn't follow. Just because something is an open forum does not mean it is automatically democratic. Indeed, this is just such an example. Mozilla is not democratic. The module owner gets the final word. There is no guarentee that the module owner will take any input into account when making the decision. Anyway. The pref about whether to use download manager or not is a separate bug, so let's not discuss that here. Since there appear to be a lot of requests for the pref for automatic removal of completed files from Download Manager to be time-based instead of boolean, I propose we simply go with: Remember completed and cancelled downloads for [___] days. ( Clear ) ...which is nearly identical to the equivalent History pref.

FWIW: The examples in comment 48 seem incorrect to me. Using or not using the Download Manager isn't covered by this pref or this bug, it's only concerned with whether or not (or how long) a download is to be kept in the list. So "Use Manager" shouldn't be a part of the example. "Don't List Downloads" is equivalent, functionally, to what is being called "Don't Use Download Manager" - and both versions take only clearing a single checkbox to accomplish that. Nor do I really see the difference between the two examples. "( ) Remove after [ ] days" could just as easily be "Remove after [ ] days", where not having a value entered at all is the same as not checking the box. (Similarly, the other one could be re-written as "( ) Remember downloads for [ ] days".) This is just minor fiddling with the UI, and whether or not there's an extra checkbox or not is a poor comparison (because there doesn't need to be). The main point is whether or not the UI (whatever it is) belongs with History...

> Mozilla is not democratic. The module owner gets the final word. Granted. But has it reached that point? I don't like the inconsistency. Either there should be a "We're doing it this way," statement, or a "Let's continue with free discussion for now," position. If it's a "done deal" that this preference will be controlled from the history UI then it should be stated so we don't all waste our time arguing against it; if it's still not decided, then discussion shouldn't be discouraged. (Nor do I think, now, that it has been discouraged as I misinterpreted a comment - as I posted.)

I don't think we can say that this is totally separate from the matter of the pref for whether to use the download manager. If the user does not want to use the manager, no items should be visible in it at all in my opinion. Such users should be able to think of downloading in exactly the same way as IE. As such, it is only if that pref is enabled that the matter of whether the stopped/completed downloads should be kept is important. Otherwise the download manager should never need to be seen at all. It might even be simpler to hide the menu item if the manager is not enabled. Am I following a different path to other people here?

> I don't think we can say that this is totally separate > from the matter of the pref for whether to use the download manager. The two are definitely related, but I don't think that they should be treated as being part of the same bug. (Already they are different bugs.) I would certainly say that the default preference here should be determined by how the download manager preference has been configured. Unless somebody specifically overrides the settings in this pref, it should not keep track of downloads if the DM is not being used - conversely, if the DM is being used, downloads should be tracked. Still, I can see how some people would not want to see the Download Manager window, but STILL want to keep track of downloads for historical reasons - viewing the DM manually via the Tools menu. So I don't think that there should be a "hardlinked" relationship between the two, just a default relationship.

I didn't realise the issue of whether this should be linked to history prefs was still being discussed; certainly I don't personally think it should. Eventually I'd like the download manager to be a totally separate component, and at that point the history prefs wouldn't even appear in the download manager pref panel.

How about if: - completed downloads stay for that session; then they go to some "completed downloads" list - accessible from the download manager (menu?) - failed/canceled downloads stay for that sessio, then nirvana.

I don't think comment #55 is a great idea, because not only will it add more complication, but when we get more download manager functions (retransfer etc), these will be harder to use.

I wasn't aware that anyone thought we were going to use the History UI for this. I thought it was obvious the suggestion was to leverage a UI pattern that was known to work in history, for an equivalent need here. BTW, I agree that if you're not using the DL mgr, there should be no record of downloads kept, that is a serious defect. Anyone who wants the record can just use the DL mgr, nobody ever even suggested they wanted such a record when using the progress dialogs Also, any use of negative numbers would be very bad from a usability standpoint.

> BTW, I agree that if you're not using the DL mgr, > there should be no record of downloads kept, I already don't use the Download Manager, just a progress window, and I get history. Admittedly I consider this a bug, but only because there's no way I can stop it from doing this. A session window is smaller and less obtrusive than the Download Manager window, so it's less distracting to use. But surely there must be some people who will want to manually check their download history from time to time even though they "only" use a progress window?

Whether this last point is a bug or not is an issue for another bug report.

"BTW, I agree that if you're not using the DL mgr, there should be no record of downloads kept, that is a serious defect. Anyone who wants the record can just use the DL mgr, nobody ever even suggested they wanted such a record when using the progress dialogs" Possibly. The original design was modeled somewhat after AOL, which always shows you a progress dialog, but which still stores finished download information until you remove it (download manager preferences have a "[ ] Retain information about my last [ _____ ] downloads").

I think there is some confusion about "use download manager." Comment #60 addresses this correctly. The "download manager" IS being used for downloads; the only control over it's use is the retention of download history, right? The infamous bug 132440 is really only about which UI to display during downloads, if any. (The pref exists to actually show nothing.) This bug will address the remaining functionality of the download manager, and whether or not it has an effect. I can live with Hixie's suggestion in comment #49, though I still think non-technical users may not figure out how to keep history forever as quickly. And I do think this pref should go on a panel with the UI selection pref.

> I still think non-technical users may not figure out how to keep history > forever as quickly. So why is this not a problem with the browsing history preference?

>So why is this not a problem with the browsing history preference? I think that there are far more people who will want to keep download history forever than are those who want to keep browser history forever.

Really? My intuition tells me that the exact opposite would be the majority view, and that most people would be more concerned with keeping browser history than with keeping download history. (Once you've downloaded something, you rarely need to download it again - but once you've visited a Web site, especially if it's useful, you frequently *DO* want to visit it again...)

I'm not talking about keeping history at all, but keeping history forever. I agree that more people would want 10 days of browser history than 10 days of download history. But you would be hard pressed to find anyone who wants to keep browser history forever, while there are those who would rather manually clean their download history. When I was using a download manager, there were certain downloads that I kept forever so that I could easily get them again if I wanted to.

*** Bug 150356 has been marked as a duplicate of this bug. ***

FWIW, my vote is to behave similar to this: -- Download Manager Cleanup -------- [x] Remove completed downloads from manager after [ _ _ ] days The number of days can be zero, I think most people would be savvy enough to figure that out (as a reminder we could make the system default zero). I figure, anyone who wants to keep a file more than, say, 99 days should not enable this option and manually delete their downloads, and the people who want the completed download entries long enough to find the file can live with them for 1 day, even if they would rather the entry stay for, say, 1 hour or 1 browser session. In the interest of simplicity, this would be a good solution.

I'm in favor of the single pref: [X] Keep completed transfers in the Download Manager More than that seems a little extensive. The user can simply scratch head, wonder why the manager is behaving in this irksome way, seek a pref, go click, and be happy again without a bunch of excess UI and decisionmaking.

Bad idea, because it is at least useful to be able to see and access completed downloads during the current seesion. Let's not whittle this down to meaninglessness. I still think comment #15 is the way to go.

A workaround should be to make the file downloads.rdf in your profile have only the following content: <?xml version="1.0"?> <RDF:RDF xmlns:NC="http://home.netscape.com/NC-rdf#" xmlns:RDF="http://www.w3.org/1999/02/22-rdf-syntax-ns#"> <RDF:Seq about="NC:DownloadsRoot"> </RDF:Seq> </RDF:RDF> Then make it readable, but not writable to Mozilla. I havn't tested this yet. Maybe Mozilla resets simple write flags (so you have to do ownership tricks on Linux), but it shouldn't.

> Bad idea, because it is at least useful to be able to see and access completed > downloads during the current seesion. Let's not whittle this down to > meaninglessness. I still think comment #15 is the way to go. And I think the proposal in comment #15 is just too bloaty and complex. If we took that route we would add FIVE prefs to Mozilla, while my suggestion in comment #67 only adds two. In fact, I've reconsidered my pref; I think we shouldn't even offer the option to keep downloads forever. I seriously doubt anyone wants to do that. We should only have one pref--how many days (0 to 99) to keep downloads in the download manager. After 99 days it's safe to assume the file isn't important to the user anymore. Therefore, the pref should not even have the checkbox, and look like this: -- Download Manager Cleanup -------- Remove completed downloads from manager after [ _ _ ] days Again, to remove downloads instantly, this could be set to zero (I won't even begin to say how stupid it would be to have zero mean keep the downloads forever). I suppose it could also be removed at the end of the session if it's set to zero, but that would still create a clutter problem (less of one after bug 134824 is fixed). Another reason why zero should not last for the session is that a session can end unexpectedly (closed wrong window, forgot you had a download in the manager, crash, etc.) so people who want a reminder where the file is should have a grace period of a day, since a session is so variably short. People who hate the clutter can set it to zero and the downloads then should disappear right after they complete. I do like the idea of a "notify the user" pref, but that should always be available and independent of the auto-removal pref we're discussing here. In that case it should be filed as a separate bug.

I agree that the preference dialog in comment 15 is way too complex, and I now also think that this issue is most easily addressed by a simple days to keep downloads preference. To avoid any confusion over what "0" days means, change the wording of the preference you suggested to read: Keep completed downloads for [ _ _ ] days. This way, 0 will intuitively convey the fact that they are not kept at all.

Why not? [X] Keep completed transfers in the Download Manager for [___] days. or Keep completed downloads for [ _ _ ] days. "(set this to 0 to never keep them)" or something like that.

*** Bug 157680 has been marked as a duplicate of this bug. ***

*** Bug 141794 has been marked as a duplicate of this bug. ***

Why are canceled and complete downloads are thrown together? I for example would like to have complete downloads to be removed automatically, but not canceled ones. I don't know how well the download manager handles that right now, but I think cancel shall be used in the future to stop a download and later on continue it again. Or will there be a fourth status for downloads: 1) In progress 2) Finished 3) Canceled 4) Stopped/Paused ??? I'm personally always for giving users as little options as necessary but as many options as useful and I see more than a single checkbox here. I see at least: [_] Notify me of completed downloads [_] Automatically remove completed downloads (o) Immediately (_) After current session [_] Limit download history to [____] entries Some people may like to keep completed downloads for the current session, so they can see what has already been complete, rather than guessing that by looking what has not been completed. Others may want to just see complete downloads vanishing at once, as they rather care for unfinished downloads than for finished ones. Some people certainly want to be notified of downloads, instead of having to use the current progress dialog for that (like IE does it if you wish). And other people want that all downloads are kept, but they don't want that the history grows endless, so giving them the ability to limit it to a certain size (numbers of lines kept) makes sense. Whenever a new line is added and it exceeds the maximum number of lines, the oldest one is removed, *unless* (and that is important) it's not finished (if you set it to 5 lines and 10 downloads are active, of course all ten are displayed, but 5 are removed when they are finished). Mozilla needs a really good download manager to compete with Opera, as the one of Opera is very good, but not customizable. IE has no such beast at all. But I don't see why after so many years of browser development people are still forced to use external download tools instead their default browser.

Just call me stupid, but I think this a privacy issue. I don't like download manager, so I tell Mozilla to open a dialog when I download something. I don't see it again and forget about it, and when I download files there is _nothing_ telling me that the files are being added to the list. Then someone else uses my machine, opens download manager and sees my history of downloads. Very bad.

Just to add my two cents, I never used the Download Manager until I upgraded from 1.0 to 1.2beta yesterday, and Download Manager use became the default action. I'd noticed under Moz 1.0 that downloads had gradually become very slow and would cause Mozilla to hang temporarily (for about 5-10 seconds), both at the start and end of the download. Now that Download Manager became the default action, I discovered for the first time that Download Manager had been keeping track of every download and save that I'd done since I built my machine and installed my first version of Mozilla some 9 months ago. It seems that the time it takes to add or update a download to the Download Manager's very long accumulated list was the cause of the slowdowns and hangs. Once I cleaned out all the entries, downloading became fast again and the hangs disappeared. Because the retention of entries in the Download Manager has, over time, a substantial impact on Mozilla performance, I suggest that changing it to allow a periodic and automatic cleanup of old entries is not merely an enhancment, but a correction to a present condition that otherwise substantially impairs Mozilla's performance.

Comment 79 and comment 80 are both good reasons to upgrade the severity of this bug to normal. Note, however, that this is based on the initial comments of this bug: > There should be some method of having files that have been successfully > downloaded automatically removed from the Download Manager list. and not the summary, which requests the addition of a preference and UI to control the behavior of automatic removal. We could dodge the issues and comment 79 and comment 80 reasonably well by having Mozilla automatically remove completed downloads upon finishing, or choosing some other default behavior to work with until a complete pref/UI is built.

> Note, however, that this is based on the initial comments of this > bug...and not the summary, which requests the addition of a preference and > UI to control the behavior of automatic removal. I'm the reporter of the bug and I wrote the Summary and the initial comments. There is no confusion here. A preference is by no means incompatible with "automatic removal" - the preference set by the user defines the interval of time after which the automatic removal will take place. To repeat, this bug is about setting a preference for the automatic removal of downloads. (Whether these be successful downloads or not is another point for discussion.) This bug is not about having successful downloads removed right away without asking the user. (Unless that is explicitly chosen by the user in via some preference mechanism.) Removing from the list without getting permission is, in my mind, *almost* as bad as keeping them in the list forever without getting permission. Every comment up to comment 78 talks about a preference - the only thing really in debate here is what kind of preference and what the UI for it should be. I still stand by comment 72.

*** Bug 172834 has been marked as a duplicate of this bug. ***

*** Bug 177521 has been marked as a duplicate of this bug. ***

If nobody minds, I will take this bug as soon as I get bug 163884 checked in (don't want to have too many open patches on the same component at once)

I have a tendency to batch download several hundred *.jpg and *.rm files in one go using http://leech.mozdev.org/ , which of course is extreme, but I know of at least two people who have swithed to Mozilla + Leech because of the functionality they offer together. I and the others can't use the wget version of Leech or any other external download manager due to autorisation issues on the website in question. Thus, 1) I have had severe problems with the download manager automatically keeping all downloaded files. I once had to delete a downloads.rdf that was 1.2MB in size 2) I could really go for an option to remove immediately or shortly after, but can live with delete after session 3) I've observed the same slowdown as described in comment 80 - It seems as if downloads.rdf is written to each time a download is registered 4) It's also a usability problem - do you actually remember to set a for you resonable retension period if the default behaviour is forever ??? or manually do a periodical cleanup in the list ??? I know of several people for whom I've installed Mozilla that won't notice Furthermore, at present the Mac OS X version of the download manager is rather broken (bug 155426) so I'm not even able to manually remove the completed downloads but have to resort to deleting downloads.rdf periodically

I don't agree with the Summary change - it doesn't add anything not already expressed.

nsbeta1- per the nav triage team.

workaround for automatic clearing of download manager when closing Mozilla this will work on *nix systems (tested on MacOS X 10.2.1) 1) quit Mozilla 2) find 'downloads.rdf' in your profile 3) open in a text-editor 4) keep the first 3 lines and the last - delete all others 5) save this reduced 'downloads.rdf' overwriting the original 6) modify the permissions : chmod 400 downloads.rdf which will set it to be read-only - also to Mozilla After this Mozilla will thus not be able to save information about new downloads to downloads.rdf - and you will in effect have implemented a 'Clear on Quit'.

Thanks for the workaround! I just implemented this on my Windows XP system. It should also function under NT and 2000 - assuming that you are using NTFS where you can set file permissions to read-only. No more bloated download lists for me.

That workaround also works for win 9x ("attrib +r downloads.rdf" or properties dialog). Much more seriously though, in trying this out, I found I had a 70kb file, despite the fact that there were no items in the manager; is that also filed somewhere?

Phil, what you describe sounds like bug 142824, which is verified fixed. Consider upgrading to the latest-trunk build, creating a new profile, and attempting to reproduce the problem. If you can reproduce it, reopen that bug.

bug 182045 sort of related, not sure if it is slightly conflicting.

This is very much needed. One reason for it's importance is that many users prefer to not show the download manager. They never even see or know that their downloads accumulate forever, and since access to RDF files seems to be at least linear, their save function gets increasingly slower. (see e.g. http://www.mozillazine.org/forums/viewtopic.php?t=2469) I think this is very much needed and there should be a reasonable default of keeping the entries, e.g. the same amount of time as the history. An intial solution could look exactly like history: Remember downloads for [x] days (Clear Downloads) where x=0 would mean to delete immediately after the download. This should be located in the "Downloads" page of the preferences.

I have found a simple work-around for this bug that will keep the DOWNLOADS.RDF file from growing. Delete all entries in the Download Manager and then mark the DOWNLOADS.RDF file as read-only. Based on my very limited testing, this appears to be effective. The download manager appears to continue functioning normally. If you open the Download Manager, all files you are currently downloading or have downloaded during the current session will be listed, but the file is not updated. If you exit and restart Mozilla and reopen the Download Manager, it will be empty.

*** Bug 191662 has been marked as a duplicate of this bug. ***

Adding 'downloads.rdf' to summary (duplicates).

I've had a patch to automatically remove downloads from the download manager when they complete. Since I noticed it was similar to Blake's I changed it to be an update of his old patch. Pref is browser.downloadmanager.storeInactiveDownloads UI in the downloads panel is [X] Remember finished and cancelled downloads in the download manager Default is current behavior (keep everything). If someone wants to add on the time based deletion, that's great. But this bug has gone in circles for a year and doesn't appear to have anybody actively working on it. I wanted something that is at least good enough for my needs and doesn't require twiddling file permissions in the profile to work around a relatively simple task in Moz.

*** Bug 204467 has been marked as a duplicate of this bug. ***

*** Bug 207899 has been marked as a duplicate of this bug. ***

While implementing automatic removal of completed files from the download manager would work around the performance issue (downloads.rdf), it doesn't solve it. Users still wishing to use the download manager should not have to put up with an O(N) search. I have just created bug 210282 as no one seems to have reported it officially.

Download Manager is nothing more than a glorified log file, in this case the file downloads.rdf. As the log file increases in size, it begins to affect the performance of other downloaded files -- they take longer to initiate. Furthermore, it is not a straight forwards process to remove the entries contained in downloads.rdf. One highlights them -- in small batches if one is smart -- then deletes or removes them. My computer (W98, 450 MHz P2) is then siezed for the 30 or more seconds while that process plays out. For what? For those who truly need a history of what they downloaded, a tiny minority I am sure, the preference should exist to accumulate such records in a log file, which should be turned off by default for the rest of the world. Once the download completes, any entry in the log file is removed. I've taken to zapping downloads.rdf with every reboot. I don't want it, and I don't want to see it, especially since that file affects performance as the log file grows larger.

(In reply to comment #102) > I've taken to zapping downloads.rdf with every reboot. I don't want it, and I > don't want to see it, especially since that file affects performance as the log > file grows larger. the workaround is to make the downloads.rdf file read-only

The "make readonly" hack is useful, but a hack an probably too involved for many users. So - until somebody comes up with the optimal solution of time-based removal with alö bells and whistles - why not implement a preliminary way to avoid the accumulation of entries in the downloads.rdf file: make a preference option of not writing the download log into the downloads.rdf file. One would have to look in detail when that file is written now, but whatever the behavior - it would be a simple way (and probably easy to implement) to get what the readonly hack does but make that option available to all users.

MultiZilla - <http://multizilla.mozdev.org/> can be set to automagically clear downloads.rdf when shutting down mozilla.

Firefox offers the option of clearing the download list once per session or even immediately after each download. I don't find the bug for that. I don't know but could we port (some of) the changes? Here is the UI for the pref: +- Download Manager -------------------------------------------------------+ | | | [x] Show Downloads window when a download begins. | | [x] Close the Downloads window when all downloads are complete. | | | | Remove files from the Downloads window: [ Upon Successful Download :^] | | When Firefox Exits | | Manually | +--------------------------------------------------------------------------+ pref is browser.download.manager.retention

YES !!!! The feature is in Firefox, and Mozilla needs this sorely. I have to remember to clear out thedownload manager manually, so it does not become too large and so download dialogs do not slow down to a craw. Add this to Mozilla now !

Do note that this issue is even worse than just the issue of having to remove those download entries manually. The manual removal, if done via the GUI interface, can take an incredible period of time. 10 seconds per entry on my machine. See bug 242521 . Please put the browser.download.manager.retention pref into Mozilla ASAP.

*** Bug 248649 has been marked as a duplicate of this bug. ***

Implementation of bug 251337 may provide an elegant workaround...

Assuming it's a backend fix rather than just Firefox specific. And, if it is a backend fix, then bug 251337 is just a duplicate of this one...

If our only concern were to limit the length of the downlad manager history, then I could agree with this. However, I think the feature requested in bug 251337 would have additional benefits (for instance, improved privacy) and would, generally spoken, make mozilla (firefox) a more consistent unity...

Obviously you haven't read all of the comments in this bug. The solution mentioned in bug 251337 is nothing more than a subset of this bug. It was already mentioned here as early as comment 13 (over 2 years ago) and has been brought up many other times since.

-> fx dl mgr

Ben, shouldn't the Product have stayed at "Mozilla Application Suite" instead of being changed to "Firefox"? This could make it harder to find in bug searches.

I'm the original reporter, and I filed it against Mozilla, not Firefox. If somebody wants to do this for Firefox, they should file a separate bug. -> Mozilla Application Suite.

So it there any built-in solutions for this yet ?

Download manager fills up with files already downloaded and this really slows down lpad performance over time. There is no statisfactory way to dump the already downladed list. THe most you can slect is one screens worth of old previously downloaded files, and it still takes a very long time to delete those files from the list. There is apparently no select all feature, and the time it takes to clear the list is horrible. Is there any simple quick and easy way to clear out the cash of previously downloaded files. For exxample is there a file the user could delete to get performance back up to par?

(In reply to comment #118) > is there a file the user could delete to get performance back up to par? It's listed in the title - downloads.rdf

> For exxample is there a file the user could > delete to get performance back up to par? See comment 70.

I agree with comment #4 from Jason Bassford. He said, "I see this bug as an actual bug to be fixed rather than an "added feature". (Retention of download history should be the added feature.)" There is now question in my mind that the manner in which the ever expanding list of downloads deteriorates download performance speed over time that it is a major bug and must be corrected as Jasson suggests.

I have a derivative of attachment 115264 [details] [diff] [review] ("boolean pref to keep finished downloads") that removes successful downloads from the list and leaves failed/cancelled downloads. The backend part is done, and for the UI I'm going to add a single check box which will say something like, "Remove successfully downloaded files from the download manager". The other options people came up with are way too complicated. This will make it easy to forget where you downloaded a file to, but I don't see any solution there. Since I'm leaving it off by default, anyone who turns it on will be enough of a power user to deal with it ;).

If browser.downloadmanager.storeCompletedDownloads is true, nothing changes. If it's false, successful downloads are removed, and bug 260818's alert is made non-clickable.

How about a simpler preference name like "browser.downloadmanager.history"?

(In reply to comment #124) > How about a simpler preference name like "browser.downloadmanager.history"? I don't think that conveys what it does.

Comment on attachment 184784 [details] [diff] [review] backend patch yea, looks ok from a technical standpoint.

(In reply to comment #121) > There is now question in my mind that the manner in which the ever expanding > list of downloads deteriorates download performance speed over time that it is a > major bug and must be corrected as Jasson suggests. It seems symptomatic of craposity in the more general list handling in mozilla/firefox. When the history grows too large, deleting single entries, let alone deleting most of the history (to make firefox usable again -- otherwise simply opening tabs takes a few seconds) sends firefox into an almost-endless loop of opening file, writing to disk, closing file, sorting, opening file.... (see 271016). So we've had to put up with 5 year old bugs that slow mozilla down in history management, the download manager, bookmarks (I recall bookmark handling being incredibly slow a few years back) and probably other lists that have been fixed over the years that I've managed to forget about. What is mozilla doing to its lists? Bogosorts? Why does it take 2 seconds simply to append a single item onto a history list, or download manager list?

Nominating for blocking-seamonkey1.1a There's a patch already, it only needs a superreview, and the target milestone is SeaMonkey 1.1a. Of course, a spot for the UI is still needed. I think the "When a download starts" rectangle could be less wider, and then you could include a "When a download completes" rectangle next to it with the option. It makes sense to me.

Seems to me SM should use the same pref as FF: browser.download.manager.retention Many people would be pleased to have it included in SM 1.1, even if the UI for it still needs to be decided upon. I think at least this much should block 1.1. Since I have no use for a download manager or for inexplicable slowdowns due to every file save getting added to the useless downloads.rdf file that never gets attended to except manually, my FF pref is set to 1.

Enhancements don't block a release. Would probably be nice to have, but we won't hold the release for this.

Comment on attachment 184784 [details] [diff] [review] backend patch I think FF got it right with having three modes: never remove, remove on quit and remove immediately. Though it'll look a bit ugly right below "browser.downloadmanager.behavior", I'd also like to use their pref name.

Move to toolkit download manager made this a dupe of bug 251337.

It looks like bug 251337 was resolved FIXED a year ago. Yet, there is still no preference that I see in the download manager for never keeping downloads. (Nor has there ever been, that I'm aware of, since 2008). Explain how this is a duplicate of a closed bug when what this bug wants still isn't available. (Hopefully I'm just missing something.)

It might be that what you want is actually not removal after a specific time but not keeping the list at all, which the browser.download.manager.retention pref should be for and which is supported by the backend in SeaMonkey 2.0 Beta 1 and later, but not exposed to or followed by the UI correctly until bug 487675 is solved.

Ah! Excellent. For those following this bug, just go into about:config and set browser.download.manager.retention to 0.