User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.17) Gecko/20080829 SeaMonkey/1.1.12 When you download files again and again over the course of many months, the Download Manager window might become very very long. In my case it had over 250 files I think. In such situation, if you want to keep two or three entries but delete the rest, the normal procedure is to Select All, then Ctrl-click and de-select the two or three you want to keep listed in the Download Manager (for later reference or whatever). When you click "remove from list" CPU usage jumpts to 100% and the user interface stalls until the list has been "purged". This can take a LOT of time, and in my case took about 30 seconds with an unresponsive UI and CPU usage pegged at 100%. (This is a single core AMD Athlon 64 2.0Ghz with 1GB RAM) I think the list purge algorithm could get a great speed-up by optimizing it. For instance if the number of entries you want to keep on the list is less than half, then it takes less time to build a list of entries to keep and build a new list of those to be kept rather than building a list of files to delete and then doing a lot of recursive delete operations. Or, the download manager window could use a database rather than sequential operations which is what it feels like it's doing. Reproducible: Always Steps to Reproduce: 1. Fill your Download Manager window with 200+ entries 2. Select all but two or three entries 3. Select "remove from list" Actual Results: Very S-L-O-W delete process. No progress or information dialog "Deleting entries, please wait"... nothing, just a stalled user interface with the button pressed down and you can't do nothing until it finishes. Expected Results: Either: 1. Show a dialog and a quick progress bar showing the deletion process 2. Make the deleting process work in the background, returning control of the UI to the user or 3. Use a database back-end for storing this information so that deleting entries on a long list isn't super-slow.

Option 3 of your expected results will happen with Bug 381157 (Which is Blocking SM2)... And probably will resolve these symptoms

I, too, have experienced this same problem. I download hundreds of files, daily. When I need to clean up the entries in the Download Manager, I need to be selective as to which entries stay and which ones get removed. I use the same 'select and remove' method as was described by the original poster. If I only delete a few entries at a time (like 10 - 20), it doesn't take quite so long, but it still runs the CPU up to 100% usage and can take up to three or four minutes. (I am running a Pentium-3 1-ghz cpu.) But when I attempt to delete several more (like 100+) from the list, I might as well go take a nap because it will probably take a half hour or longer to do the purge. I can't imagine why this should be such a cpu hog for such a simple operation.

Dupe of (i.e. resolved by) bug 380250 now that we landed bug 381157.