314765 - Firefox UI seems to be single threaded

Status: RESOLVED DUPLICATE of bug 40848

(Firefox :: General, defect)

Description

[Bert]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051025 Firefox/1.5

Whenever I download a file, or navigate to a new URL on a different open Firefox 
window, the UI of all the other open Firefox windows freezes.  I can't access pull down menus, context menus or even click on links.  The events are captured, but not processed until the download has finished.  If I try to type in a URL in the address bar, it also won't give me focus until the download is finished, and if I somehow get a keystroke in, the possibility of crashing is high.  Some events do get through during pauses in activity, causing a jerky sort of feel.  I can download multiple files in this way (painfully) but then the downloads all happen serially, making the browser unusable for the entire time.

This problem did not occur on 1.05 and earlier.  
I was able to download up to 6 or more concurrent files.
And the browser UI did not seem "stuck" except for small bits of time.

This problem has been present on 1.5b1 1.5b2 and now 1.5rc1

I am using a dual CPU Windows NT machine (so threading normally works very effectively for me if present)  I have 1 GB of RAM, so memory should not be an issue.

Reproducible: Always

Steps to Reproduce:
1. go to any site with several download files of 1 MB or so
2. right click on one of them and download the link (going through the dialogs)
3. continue right clicking on the other downloadable links and downloading them

You can also just open 2 fairly complicated sites in separate windows.  Navigate to a page in one window, and try to bring forward the other window.  The repaint of the 2nd (already loaded) window is very slow until the 1st one finishes rendering.
Actual Results:  
The first download launches the download manager.
The right click on the second download link takes about 10 seconds to show the context menu.  The click on the save link as took about 10 seconds to activate the dialog, the click on the Save button took about 15 seconds before the dialog closed.  The right click on the third download took about 30 seconds before the context menu popped up, about 20 seconds before the dialog opened, about 20 seconds for it to close, (after this point times were relatively constant)

Clicking on any other open firefox window causes the window to take 30 or more seconds to repaint (it is frozen most of the wait time)

Expected Results:  
In 1.0.x versions, the right click might take as long as 5 secs to come up, and similarly for the dialog popup and save/close.  This allowed me to queue up download requests (up to 12 or so - with up to 6 or so concurrent)

Ideally, if the download manager and each window (as well as socket connections) were on a separate thread, then the paint delays would be less than a second.

I am using the default theme, I have installed the beta1 over the original 1.0.5 the beta2 over the beta1 and the rc over the beta2

Automatic install did not work for me except between beta 1 and beta 2.

I also noticed that the download window sometimes took focus away from the topmost browser window as it progressed (when downloads went from queued to active and from active to complete)

The issue with multiple window repaint may be a separate specific bug instance (in the code) from the download issue, because I seem to remember if present (to a lesser degree in 1.0.x) but the type of bug seems to be the same.

Comment 1

[Pete]

I too see this problem, though I think it has something to do with my firewall.  I'm running Win XP w/SP1, ZoneLabs' Integrity Flex Client and Firefox 1.0.7.  When the firewall is running, I see this behavior (though not with IE, *shudder*).  When the firewall is NOT running, I can queue up several downloads, no problem.  Can't find a POC for the Integrity Flex, though other ZoneAlarm products seem to have issues with Firefox (from what I've read on a couple of sites).

Comment 2

[Pete]

I too see this problem, though I think it has something to do with my firewall.  I'm running Win XP w/SP1, ZoneLabs' Integrity Flex Client and Firefox 1.0.7.  When the firewall is running, I see this behavior (though not with IE, *shudder*).  When the firewall is NOT running, I can queue up several downloads, no problem.  Can't find a POC for the Integrity Flex, though other ZoneAlarm products seem to have issues with Firefox (from what I've read on a couple of sites).

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to comment #1)
>...
> ZoneAlarm products seem to have issues with Firefox (from what I've read on a
> couple of sites).

yes indeed quite a few problems https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type=anywordssubstr&short_desc=ZoneAlarm+&product=Core&product=Firefox&product=Mozilla+Application+Suite&product=Thunderbird&product=Toolkit&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&resolution=FIXED&resolution=INVALID&resolution=WONTFIX&resolution=DUPLICATE&resolution=WORKSFORME&resolution=EXPIRED&resolution=MOVED&resolution=---&op_sys=All&op_sys=Windows+95&op_sys=Windows+98&op_sys=Windows+ME&op_sys=Windows+2000&op_sys=Windows+NT&op_sys=Windows+XP&op_sys=Windows+Server+2003&emailassigned_to1=1&emailtype1=exact&email1=&emailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=

Comment 5

[Brendan Eich [:brendan]]

(In reply to comment #4)
> 
> *** This bug has been marked as a duplicate of bug 40848 ***

I think this is not a dup of that bug. From comment 0:

"This problem did not occur on 1.05 and earlier."

Bert, are you using ZoneAlarm or similar?

/be

Comment 6

[Bert]

Hi Brendan, 

Sorry for the delay in responding - work has been very busy.

No ZoneAlarm or anything similar on any of my machines.  I use a hardware firewall in all cases.  I do have virus checking (2 different kinds) on 2 of my machines, but nothing at all on my home desktop rig (the WinNT box)

In any case, at this point, my comment of "This problem did not occur on 1.05 and earlier." was more anecdotal than something I tested to exhaustion.  I should probably rephrase it to -> I did not notice this problem on 1.05 and earlier even though my downloading habits have not changed.

In other words, if it was there, I probably compensated for it and ignored it, since the delay wasn't too huge.  Possibly something exceeded a noticeability threshold as more features got added into the browser and began competing for resources.

Currently, if I want to improve my responsiveness in selecting files for downloading, I just wait for the system to settle (could take awhile) and then I clear the download screen.  Responsiveness returns for awhile until I fill up the download history again.

I'm not suggesting that I'm not impacted by bug 40848 in all of this (I certainly am and notice those effects too), I am however suggesting that something in the way the download history is stored or rendered is causing additional grief (the normal rendering problems due to 40848 seem to get worse).
Perhaps fixing 40848 may improve the situation with respect to this effect.

Regardless, the download window doesn't have to be open (or to ever have been opened within a session) to get the delay effect due to excessive history.  Although having the download window open does slow down the UI overall as per bug 40848 and I've noticed small 0.5 second freezeups when I'm typing in the address bar of the active browser window and the download window is trying to update a progress bar (noticeable only when the effect is active).

Also, when I don't have so many concurrent windows open, the responsiveness impact is still there (not as bad) and can still be ameliorated by clearing the download window.

So, to more fully answer your question, the only thing I have on my WinNT setup that impacts Firefox is Flash and FlashBlock.  Nothing else.  And I can see the problem with purely non-flash sites.  

Also, I have very little running even in the background on my WinNT box.  I have an old old version of RealPlayer (that I've never used in conjuction with a browser), an Apache HTTPD server, and an old WinAMP. No Real Player or WinAmp on my work machine.  The only thing I have on all my machines is the Apache Server, and I somehow don't think that's it.

Regards,
--Bert

Comment 7

[Bert]

Just an additional note.  When I wrote the original issue, I was describing the overall effect (a problem report), not so much trying to separate out the individual bugs.  There are probably at least 2 or 3 bugs in there - bug 40848 is certainly one of them, but there is certainly something else related to downloading and download history.  Possibly one bug referring to how concurrent downloads are managed and one relating to a responsiveness hit when the download history is "full".  

I used to use flashgot to overcome the problem of concurrent downloading (flashgot with getright does a much better job of queing background downloads) but I had to stop using it when it failed to follow one of the Mozilla upgrades and I haven't really bothered since.