Closed Bug 132755 Opened 22 years ago Closed 15 years ago

Add preference for automatic removal of completed files from Download Manager/downloads.rdf.

Categories

(SeaMonkey :: Download & File Handling, enhancement)

Product:
SeaMonkey
Component:
Download & File Handling
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 251337

People

(Reporter: jasonb, Unassigned)

References

Details

(Keywords: privacy, Whiteboard: [cst: sr? 1yr+, find space in dl pref pane for new checkbox])

Attachments

(4 obsolete files) 

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
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?
Severity: normal → enhancement
Summary: Automatically removing completed files from Download Manager. → Automatically removing completed files from Download Manager
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.
Summary: Automatically removing completed files from Download Manager → Add preference for automatic removal of completed files from Download Manager.
*** 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.
Blocks: 75364
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. ***
Attached patch patch (obsolete) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
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.
Keywords: privacy

    
  
Keywords: nsbeta1
QA Contact: sairuh → petersen

    
    

    
  
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.

    
  
Keywords: mozilla1.2, 
          
            patch

    
    

    
  
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.
Severity: enhancement → normal
Keywords: perf

    
    

    
  
> 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

    
  
Keywords: mozilla1.3, 
          
            review

    
  
Summary: Add preference for automatic removal of completed files from Download Manager. → Add preference for automatic removal of Download Manager entries (completed files)

    
    

    
  
I don't agree with the Summary change - it doesn't add anything not already
expressed.
Summary: Add preference for automatic removal of Download Manager entries (completed files) → Add preference for automatic removal of completed files from Download Manager.

    
    

    
  
nsbeta1- per the nav triage team.

Keywords: nsbeta1 → nsbeta1-

    
    

    
  
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).
Summary: Add preference for automatic removal of completed files from Download Manager. → Add preference for automatic removal of completed files from Download Manager/downloads.rdf.

    
  
Keywords: mozilla1.2

    
    

    
  


  
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.

        Attachment #93458 -
        Attachment is obsolete: true

        Attachment #93459 -
        Attachment is obsolete: true

        Attachment #115264 -
        Flags: review?

        Attachment #115264 -
        Flags: review? → review?(blaker)

    
    

    
  
*** 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.

    
  

        Attachment #115264 -
        Flags: review?(firefox) → review?(bugs)

    
    

    
  
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.
Product: Browser → Seamonkey

    
    

    
  
-> fx dl mgr
Assignee: firefox → bugs
Flags: review?(bugs)
Product: Mozilla Application Suite → Firefox
QA Contact: chrispetersen → bmo

    
    

    
  
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.
Product: Firefox → 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.


Assignee: bugs → cst
Keywords: helpwanted
Priority: -- → P5

    
    

    
  
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 ;).


Severity: normal → enhancement
Status: NEW → ASSIGNED
Keywords: helpwanted, 
          
            perf
Whiteboard: [cst: make sure bug 260818's clickable text doesn't do something stupid]
Target Milestone: --- → Seamonkey1.0alpha
Whiteboard: [cst: make sure bug 260818's clickable text doesn't do something stupid]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        backend patch (obsolete)
        — 
          — Splinter Review
      

    


  
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.

        Attachment #115264 -
        Attachment is obsolete: true

        Attachment #184784 -
        Flags: superreview?(neil.parkwaycc.co.uk)

        Attachment #184784 -
        Flags: review?(timeless)

    
    

    
  
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.
Whiteboard: [cst: r?,  find space in dl pref pane for new checkbox]

        Attachment #184784 -
        Flags: review?(timeless) → review?(db48x)

    
    

    
  
Comment on attachment 184784 [details] [diff] [review]
backend patch

yea, looks ok from a technical standpoint.

        Attachment #184784 -
        Flags: review?(db48x) → review+

    
    

    
  
(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?
Target Milestone: seamonkey1.0alpha → seamonkey1.1alpha

    
    

    
  
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.
Flags: blocking-seamonkey1.1a?
Whiteboard: [cst: r?,  find space in dl pref pane for new checkbox] → [cst: sr? 1yr+,  find space in dl pref pane for new checkbox]

    
    

    
  
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.
Flags: blocking-seamonkey1.1a? → blocking-seamonkey1.1a-

        Attachment #184784 -
        Flags: superreview?(neil) → superreview?(jag)

    
    

    
  
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.

    
  
QA Contact: ali → download-manager
Assignee: cst → download-manager
Status: ASSIGNED → NEW
QA Contact: download-manager
Assignee: download-manager → nobody
Priority: P5 → --
QA Contact: download-manager
Target Milestone: seamonkey1.1alpha → ---

    
    

    
  
Move to toolkit download manager made this a dupe of bug 251337.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE

    
    

    
  
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.)

    
  

        Attachment #184784 -
        Attachment is obsolete: true

        Attachment #184784 -
        Flags: superreview?(jag)

    
    

    
  
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.

    
  
Status: RESOLVED → VERIFIED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: