Networking: HTTP
16 years ago
15 years ago


(Reporter: David G King, Assigned: Darin Fisher)


({regression, relnote})

regression, relnote

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [pipelining], URL)



16 years ago
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.

Comment 1

16 years ago
-> networking

os -> all

No problem if you disable keep-alive, but w/o keep-alive stuff is extremely slow
to load. 
Component: Browser-General → Networking: HTTP
OS: Windows 98 → All

Comment 2

16 years ago
Assignee: Matti → darin
QA Contact: imajes-qa → tever

Comment 3

16 years ago
cc'ing PSM folks in case this has something to do with PSM.
confirming that keep-alive makes this very slow...
Ever confirmed: true

Comment 5

16 years ago
Adding keyword "regression" as it works fine with 1.0RC1.
Keywords: regression

Comment 6

16 years ago
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.

Comment 7

16 years ago
Isn't it caused by the patch for bug 125561 which landed (trunk only) on 4/19? 

Comment 8

16 years ago
The testcase WFM with the most recent 1.0 branch build (2002042506).

Comment 9

16 years ago
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. 

Comment 10

16 years ago
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.

Comment 11

16 years ago
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.

Comment 12

16 years ago
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.

Comment 13

16 years ago
> 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 :-(

Comment 14

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

Comment 15

16 years ago
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.

Comment 16

16 years ago
That site WFM on 2002050807 win2k

Comment 17

16 years ago
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.

Comment 18

16 years ago
reducing severity to major since this only seems to happen when pipelining is
Severity: critical → major
Whiteboard: [pipelining]

Comment 19

16 years ago
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.
Keywords: relnote

Comment 20

16 years ago
mass futuring of untargeted bugs
Target Milestone: --- → Future

Comment 21

16 years ago
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.

Comment 22

16 years ago

*** This bug has been marked as a duplicate of 144442 ***
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 23

15 years ago
verified dup
You need to log in before you can comment on or make changes to this bug.