265255 - Enqueueing a lot of files to download causes mayhem (hang)

Status: RESOLVED INCOMPLETE

(Toolkit :: Downloads API, defect)

Description

[Rory Kiefer]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20041001 Firefox/0.10.1

When enqueueing about thirty to fourty files to be downloaded (right clicking 
on link and clicking "save link as") eventually 12 to 15  download manager 
windows pop up, cpu usage spikes to 100%, and firefox.exe occupies 230+megs of 
ram (on a system w/ 512).

This only occurs in waves, since as you queue the files to download, it wont 
ask where you want to save them to unless the first few you've selected are 
finished. Following this cycle allows the buildup of many many "right-click, 
save link as"'s to go without a response until the download manager completes 
a download or so. Massing these up is what I believe to cause the large number 
of Download Manager windows to open. 

Reproducible: Always
Steps to Reproduce:
1.go to a page with a lot of links
2.start on the top of the links and work your way down every one, right 
clicking and pressing "k" to induce a "save link as"
3.continue doing so and eventually the download manager goes bonkers

Actual Results:  
mem/cpu usage spike, firefox not responding

Expected Results:  
peacefully enqueued the files to download

No plugins/themes/extensions used

Comment 1

[Rory Kiefer]

* this requires a large amount of links to large files to work as the
"right-click, save-link-as" process must be done to each link without waiting
for the download manager to actually open and ask where to save it.

process:

(after a couple of large files are in the middle of downloading)
right click on link, press k
immediately right click on next link, press k
immediately right click on next link, press k
...
eventually after the two files that were downloading while you were clicking
finish, you will be asked where each individual file you chose to "save-link-as"
goes and the files are enqueued. If you repeat this process and get abour 30 or
40 enqueu statements built up, the problem occurs.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Firefox download manager is a different beastie from the Mozilla one...

Comment 3

[Henrik Ræder Clausen]

After downloading some 70+ files, the download manager becomes slow and
eventually hangs Firefox. Restarting the browser resets the problem: It works
fine until you download another 70-something files. 

I used Larabie Fonts (www.larabiefonts.com) to produce this problem.

Comment 4

[Simon Lieschke]

I think this happens because Firefox maintains a maximum of two connections per
server as prescribed by the HTTP specification. The Save As windows only appear
once one of the first two files from the server have finished downloading.

The lack of immediate feedback when attempting to save a third file is rather
annoying. Perhaps Firefox should display the Save As dialog immediately, and add
the download to the Downloads window once the user has selected a location for
the download. The file could then start downloading once one of the two files
already downloading from the server has finished.

Comment 5

[Rubén Martín [:Nukeador] ❌ [away till Aug 31st]]

If the download manager list is too big, FF became unstable because of the
memory usage and CPU usage.

Comment 6

[Robin Monks]

Confirming based on comments and IRC feedback from Bug-A-Thon.

Comment 7

[Glenn Qiu]

[quote]
Firefox download manager is a different beastie from the Mozilla one...
[/quote]

how is the ff download manager from the one in toolkit?

Comment 8

[Shawn Wilsher :sdwilsh]

(In reply to comment #7)
> how is the ff download manager from the one in toolkit?
It isn't, but mozilla uses xpfe.

Stephen, can you qa this please?

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Attachment: HTML testcase that spawns numerous download dialogs

Just do a File | Open File... on this

Comment 10

[Stephen Donner [:stephend] Not actively reading bugmail]

A few things:

1) This is not the best testcase, of course, but it's a relatively easy way to trigger mass amounts of download-prompt windows.
2) It might even be completely off as a testcase for this particular bug, given that at least the original reporter seems to have reported this against a single server--which particular one, and what its value for the maximum number of HTTP connections per IP address, are both unknown
3) To address #2, just replace the appropriate lines from different servers with different files from the same server

Rory, are you still around?  If so, can you try a Win32 build from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-3.0b3pre.en-US.win32.installer.exe against your original testcase, or some variation of the HTML one I've posted in comment 8?

(BTW, big thanks to Bob Clary for writing the JavaScript!)

Comment 11

[Wayne Mery (:wsmwk)]

Donner in  comment #10
> Rory, are you still around?  If so, can you try a Win32 build from
> ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/firefox-3.0b3pre.en-US.win32.installer.exe
> against your original testcase, or some variation of the HTML one I've posted
> in comment 8?

reporter's (Rory's) email address is dead.

Comment 12

[Simona Badau, Desktop QA]

Mozilla/5.0 (Windows NT 5.1; rv:25.0) Gecko/20130715 Firefox/25.0
I can't reproduce the issue on the latest Nightly as described in the Description or with the attached testcase in Comment 9.

For the time being, I'm removing the qawanted keyword. If anyone considers it's still needed or that more information from the qa side is necessary, please add it back.

Comment 13

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:mak, could you have a look please?

For more information, please visit BugBot documentation.

Comment 15

[Marco Bonardo [:mak] (away Aug 5-12, Aug 19-21)]

As the new download process is very different from the one for this bug was filed (download happens in a background thread, there's a panel instead of a separate window, file handling is quite different) I don't think it's worth keeping this around as-is.
Eventually a new bug with a performance profile should be filed if this is still a users concern.