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:.
Summary: Freze during page loading → ss:Freeze during page loading
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 :-)
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.
On fast network on NT it works ok. I'll have someone try a dialin line.
loads fine for me at my desktop. PaulMac can you take a look at this bug? Just add your comments here.
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.
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 :-)
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.
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.
Need rn from angus.
Release noted slower modem speeds issue. Taking this off rn: radar.
*** Bug 1592 has been marked as a duplicate of this bug. ***
Re-assigned to firstname.lastname@example.org. Gagan, is this a netlib bug? Who should get this?
Paul: Could I get some more details on this?
Status: NEW → RESOLVED
Last Resolved: 20 years ago
Resolution: --- → FIXED
Old bug. This page no longer freezes on load. Used Jan 25 Win 32 build. Works on Mac too. Marking Verified.
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. ;-)
Bulk move of all Networking-Core (to be deleted component) bugs to new Networking component.
Summary: Freeze during page loading → Conn: Freeze during page loading
You need to log in before you can comment on or make changes to this bug.