From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020425 BuildID: 2002042510-TRUNK This page is the login page to my bank. I'd noticed that it had become very slow to load (like more than 15 minutes). Also, subsequent pages (after I login) are also very very slow. After testing using Netscape 4.79 without any trouble, I have to say it's a bug in Mozilla. Reproducible: Always Steps to Reproduce: 1. Open URL 2. Wait 3. Wait some more 4. Go get a coffee and wait some more. Actual Results: Takes a long time to display page. Expected Results: Load in a few seconds as with Netscape 4.79 I'm marking this as Critical as the average use would consider this a Hang.
-> networking os -> all No problem if you disable keep-alive, but w/o keep-alive stuff is extremely slow to load.
cc'ing PSM folks in case this has something to do with PSM.
confirming that keep-alive makes this very slow...
Adding keyword "regression" as it works fine with 1.0RC1.
Has anyone seen this on the 1.0.0 BRANCH? I will be testing a latest BRANCH build tonight (EDT), but if someone else has already done so, it will save me the hassle.
Isn't it caused by the patch for bug 125561 which landed (trunk only) on 4/19?
The testcase WFM with the most recent 1.0 branch build (2002042506).
I've just tested 2002042506-BRANCH and it works fine. From reading Bug #125561, it looks like this may be a dup. As such, I recommend that the patch for that bug does not get checked into the Branch.
Why do you think it is the patch from bug 125561? Did somebody test a trunk build where that patch was reverted, to see whether it indeed is the cause of the problem? When I look at the context at that patch, I have the impression, that new code is only called when one of the following events is broadcasted: - "session-logout" - "profile-before-change" IMHO, until you quit the application or switch the profile in turbo mode, this code can't be the cause.
I don't have a C compiler, so I can't backout or build code. I'm guessing that your fix was applied to the Trunk on 4/19, so I'm getting a 4/18 build to try it.
A 4/18 build works fine. I can't find a Windows build for 4/20 or 4/21 so can't test that much further.
> Why do you think it is the patch from bug 125561? Simply because it was the only keep-alive patch in recent days. I have presently at home only a modem connection paid per minute, so I do not build Mozilla anymore :-(
The images load if HTTP pipelining is turned off, but not when it's turned on. Perhaps this should be resolved as dup of bug 140561, which has a more exact summary.
I'm not sure if this is a dup of #140561. There is no mention in that bug about the fact that the images will load if given enough time.
That site WFM on 2002050807 win2k
Gavin, do you have HTTP pipelining turned on? The reason I ask is that with build 20020509-TRUNK it still doesn't work for me on Win98SE.
reducing severity to major since this only seems to happen when pipelining is enabled.
Adding RELNOTE keyword as it looks like this isn't going to be fixed for Mozilla 1.0. People need to know that turning on pipelining can break page loads.
mass futuring of untargeted bugs
looks like this bug is caused by problems with IIS/4.0 ... i've seen other sites that have similar troubles. the common problem is IIS/4.0 seems to ignore subsequent requests in a pipelined request. it never responds to them, and as a result, mozilla ends up waiting for a very long time. the solution (i think) is to disable pipelining when speaking to IIS/4.0. working on a patch.
*** This bug has been marked as a duplicate of 144442 ***