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

NEW
Unassigned

Status

()

Toolkit
Downloads API
--
major
13 years ago
5 years ago

People

(Reporter: Rory Kiefer, Unassigned)

Tracking

({hang})

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
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
(Reporter)

Comment 1

13 years ago
* 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.
Firefox download manager is a different beastie from the Mozilla one...
Assignee: download-manager → bugs
Component: Download Manager → Download Manager
Product: Browser → Firefox
QA Contact: bmo

Comment 3

13 years ago
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

13 years ago
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.
If the download manager list is too big, FF became unstable because of the
memory usage and CPU usage.

Comment 6

12 years ago
Confirming based on comments and IRC feedback from Bug-A-Thon.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang
Summary: Enqueueing a lot of files to download causes mayhem → Enqueueing a lot of files to download causes mayhem (hang)

Updated

11 years ago
QA Contact: ali → download.manager
Assignee: bugs → nobody

Comment 7

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

how is the ff download manager from the one in toolkit?
(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?
Keywords: qawanted
Created attachment 297684 [details]
HTML testcase that spawns numerous download dialogs

Just do a File | Open File... on this
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!)
(Assignee)

Updated

10 years ago
Product: Firefox → Toolkit

Comment 11

9 years ago
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.
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.
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.