1631 - Conn: Freeze during page loading

Status: VERIFIED FIXED

(Core :: Networking, defect, P2)

Description

[Angus Davis]

I notice when loading pages that during a certain part of the loading process,
the client (viewer.exe, or xpviewer.exe) "freezes" for a few seconds. It seems
worse when over a modem at home. Basically, you go to a page, say,
http://www.cnn.com/, and the comet logo will start spinning. At some point in
the loading process, the logo stops spinning, the viewer will not repaint itself
(Drag windows over it and out of it to see), and is basically totally frozen.
Then, a few seconds later (in my case, to cnn.com over 28.8, it was about 9
seconds), the loading process picks up again.

Is this layout or netlib or threading? I'm assuming the last.

Note while I think this bug will hurt our performance story, it's not ss:.

Comment 1

[leger]

Filling in URL field.  I am going to send this bug to QA to see how bad they
think this is too. Will put on ss: temporarily to track.  If this consistently
happening, may need to Release Note possible delays.  Do not want folks to
think they are frozen.  Let's see how today goes :-)

Comment 2

[Paul MacQuiddy]

I've noticed this too, though it hasn't been too bad - undoubtedly cause I'm
running on my fancy new cable modem at home, and have jettisoned my 28.8. The
behavior does seem different from 4.0x - there seems to be something bad going
on.

The scary part would be if there are cases when the freeze never goes away.

Comment 3

[glynn]

On fast network on NT it works ok.  I'll have someone try a dialin line.

Comment 4

[sujay]

loads fine for me at my desktop. PaulMac can you take a look at this bug?
Just add your comments here.

Comment 5

[Angus Davis]

There is a proxy server that sets your throughput to 28.8, 14.4, etc. I forget
the details, so I'm cc'ing waterson, who knows the address. The way to make
NGLayout recognize your proxy setting is to make the setting in communicator,
quit out of communicator, and copy your prefs.js into the same directory as
viewer.exe.

Note the address of the proxy might also be somewhere in news:mcom.dev.perf50 -
didn't bother searching there yet.

Comment 6

[Angus Davis]

Forgot to mention that this CNN URL is just an example. The problem occurs on
all URLs that take a while to load. If you find a server in Timbuktu, for
example, it might better demonstrate the problem :-)

Comment 7

[Paul MacQuiddy]

The http proxy is "ducky". You can set the port to 8288 to simulate a 28.8
modem. The instructions are just as angus described, set up your communicator by
setting manual proxy in the advanced pref pane, then putting in ducky under http
and 8288 as the port, then copy prefs.js file wherever your xpviewer.exe is.

The behavior is as angus described - probably not a stop-ship, but definitely a
release note.

Comment 8

[Chris Waterson]

The proxy is internal to Netscape: ducky.mcom.com (I think this is kipp's
machine?). Use port 8144 for 14.4 and port 8288 for 28.8.

Comment 9

[leger]

Need rn from angus.

Comment 10

[leger]

Release noted slower modem speeds issue.  Taking this off rn: radar.

Comment 11

[Paul MacQuiddy]

*** Bug 1592 has been marked as a duplicate of this bug. ***

Comment 12

[don]

Re-assigned to [e-mail].

Gagan, is this a netlib bug?  Who should get this?

Comment 13

[Gagan]

Paul: Could I get some more details on this?

Comment 14

[leger]

Old bug.  This page no longer freezes on load.  Used Jan 25 Win 32 build.  Works
on Mac too.  Marking Verified.

Comment 15

[leger]

Changing all Networking Library/Browser bugs to Networking-Core component for
Browser.

Occasionally, Bugzilla will burp and cause Verified bugs to reopen when I do
this in a bulk change.  If this happens, I will fix. ;-)

Comment 16

[leger]

Bulk move of all Networking-Core (to be deleted component) bugs to new
Networking component.