Closed Bug 140176 Opened 22 years ago Closed 22 years ago

Very very slow to load

Categories

(Core :: Networking: HTTP, defect)

Product:
Core
Component:
Networking: HTTP
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
VERIFIED DUPLICATE of bug 144442
Milestone:
Future

People

(Reporter: d_king, Assigned: darin.moz)

References

(
URL
)

Details

(Keywords: regression, relnote, Whiteboard: [pipelining]) 

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.
Component: Browser-General → Networking: HTTP
OS: Windows 98 → All
reassign
Assignee: Matti → darin
QA Contact: imajes-qa → tever
cc'ing PSM folks in case this has something to do with PSM.
confirming that keep-alive makes this very slow...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Adding keyword "regression" as it works fine with 1.0RC1.
Keywords: regression
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.
Severity: critical → major
Status: NEW → ASSIGNED
Whiteboard: [pipelining]
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
mass futuring of untargeted bugs
Target Milestone: --- → Future
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 ***
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.