350162 - The download manager take all of the processor time... (Moz better than FF ?)

Status: RESOLVED DUPLICATE of bug 159107

(Toolkit :: Downloads API, defect)

Description

[Kepes Krisztian]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; hu; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6

It's look that the DM man. in FF worse than in Mozilla.
I cannot start more downloads (only one), because the DM manager is take up all of the processor time.

When the Mozilla or Opera starts one download, I can use the application, can browse, can download other files.

The Firefox freezed on the first download, I cannot do anything while the file downloading...



Reproducible: Always

Steps to Reproduce:
1. Start the download of a big file.
2. The browser freezed.
3. After the download I can work.

Like mutex protected download manager... :-)

Comment 1

[Ria Klaassen (not reading all bugmail)]

Try cleaning up your downloads manager or removing downloads.rdf in your profile and see if that helps.
http://kb.mozillazine.org/Profile_Folder

Comment 2

[Kepes Krisztian]

(In reply to comment #1)
> Try cleaning up your downloads manager or removing downloads.rdf in your
> profile and see if that helps.
> http://kb.mozillazine.org/Profile_Folder
> 

Yes. DM manager`s database was full.
When I clean it from GUI, every problem vanished.

But question is on: why it check this list with this slowly method ?
Why is not use hash database ?

I think, that DM need an "Age" field that holds a value.
This value determine the download list item persistency.
If an item`s age exceeded this value, it is removed from the list.
The possible values:
1 day, 2 days, 5 days, 7 days (default), 14 days, 1 month, 2 month, Persistent.

I thinking about that is better, because the life cycle of the items is manageable. The common user is not get this effect in this case.

Ok, now we can use automatically deletion, but manageable is better.

Comment 3

[Adam Guthrie]

*** This bug has been marked as a duplicate of 159107 ***