i think this may be a dupe, but for the life of me i can't find it. basically, users should have the ability to queue files for downloading. when a user downloads a file, the file should either be 1) downloaded immediately, 2) queued for future download, or 3) the user could be prompted as to which option is preferable. the prefs would naturally include a setting for which of the three would occur upon download. queueing essentially would delay the actual onset of the download process to a future signalled time. included in the preferences, and implicit in the use of a file queue, would be the option of the maximum number of files to download at once when the queue is initiated. the download manager toolbar would consequently include a button to start downloading the queue. while the queue is running, further user downloads would either be added to the end of the queue or would be downloaded immediately "on top" of the queue. the ability to reorder files in the queue could be a future extension of this option, but would not be a requirement.

oops, forgot to add [rfe]. so sorry for the spam.

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

this bug is not a duplicate of bug 151216. that bug asks for requested downloads to be downloaded one at a time. this bug is about placing requested downloads on a file queue for later download. i think a file queue would be more effective if the user is allowed to select the maximum number of simultaneous downloads (as opposed to the maximum number of total tcp connections). technically, however, limiting the number of simultaneous downloads (even if the limit is the current limit of 8) should not be required to allow users to place download requests on a file queue.

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

dupe of bug 151216 / you decide which goes through

this bug and bug 151216 are *NOT* the same bug. this bug can be fixed independently of bug 151216. please see comment #3 for more.

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

And add a multiconnection option to accelerate download makinf fragments like other download managers!

And add a multiconnection option to accelerate download makinf fragments like other download managers!

(In reply to comment #9) > And add a multiconnection option to accelerate download makinf fragments like > other download managers! That is Bug 75360.

I'd just like to throw my support behind a download queuer. I'm surprised noone has made an extention for this already...

Someone knows any about:config option to limit file download to 1 and queue the rest? Some servers just block/reset connection when you download few files in parallel. Sometimes it is faster to download file one by one. I'm tired to have several tabs open and to remember what I need to click when one download finishes to start another.

Any hope to have download queue in FF3.1? Downloading files 1 by 1 in queue (instead of parallel download like now) is very good thing because: 1) some servers do not allow multiple connections at a time, (so I'm kicked out when I select >1 file for download) 2) files are downloaded faster because connection bandwidth is not split to many downloads at a time, (so I get 1st file in queue immediately and can use it immediately when the next one begins to download). 3) More chances for successful download: if I browse the web and click for file download here and there FF immediately begins downloading all of them. If there are many files I want to have the total connection bandwidth is split and split to very small, slow pieces. This causes servers to disconnect due to slow transfers or no transfers at all. The result is that have zero successful downloads from working sites.

It's amazing that nobody cared to implement this feature since 2002. Or should I say fixing this flaw, because making all downloads simultaneous is a design flaw. Now it's 2014, that's 12 full years, and still waiting for the basic functionality to be implemented. Incredible lack of care about their users.

Someone please just WONTFIX this bug, and be done with it.