Using 45kbps modem connection: Load this page in Nav4 or IE5; loads quickly. Load it in Nav5; it takes a *long* time. Images take a *long* time to pain on the screen.

Chris, who gets this kind of performance bug?

the problem is suspected to be in netlib, hence the necko project. erik can you provide the urls you find most problematic and some comparison data? we will add these to legers performance testing...

On WinNT 4.0 on P2-300 w/ 256M RAM using 56k modem connection at 45333 bps: - page loads in 15 seconds on Nav4.52 - page loads in 2 minutes on M5

Deferring until after necko landing.

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. ;-)

lets mark this fixed and get it on the testing radar. If there are problems get some more details posted for study.

Eric, can you verify that this is better with necko? I don't have a 56k modem to check this on.

The problem still occurs in 8/17 Commercial Apprunner build (numbered 1999051808 -- isn't this numbering a bit odd for the date?) on WinNT 4.0 SP3 on my PII-300, *BUT* the problem appears to be that the far-left frame's image is not painting even though the image has finished loading. Here's what I saw: using the above HW and dialed in over my 56K modem: 1) loading the page and finishing display took 17 seconds for Nav 4.61 2) after 30 seconds or so (I didn't note the duration exactly), 8/17 AppRunner Commercial was displaying "document done" but the image in the far-left frame had still not displayed. After a full minute, I began to suspect that the file had finished downloading but that the image had failed to paint on the screen. I verified this by bringing the Nav 4.61 window to the top (covering the AppRunner window) and then bringing the AppRunner window to the top; when the AppRunner window reappeared, it did so with the image correctly painted. It seems that the file had downloaded but that the image paint never occurred until triggered by the window loss and regain of focus. Reopening; changed summary and status to reflect new info.

Clearing FIXED resolution due to reopen.

Eric, I'm a bit concerned that you're running an old build. The builds from yesterday at ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-08-17-09-M9/ or ftp://sweetlou/products/client/seamonkey/windows/32bit/x86/1999-08-17-11-M10/ have 1999081709 or 1999081711 as their build date. Please check again.

If this is still open with 19990816008 M9 builds, then indicate as so in this bug, and I suggest a release note for M9. Not an M9 blocker...moving to M10

I don't have a modem or slow link to try this with, but it works here on the lan. It seems very unlikely that there would be something timing-dependent going on sort of the server timing out or something. Could you please try this again and get back to me? Thanks.

paulmac, please check this. Moving to m11

I tried this on 33.6 modem, and performance is on par with 4.x. Note: you can set your proxy to chainsaw and port to 8144, 8288, 8336 for slow modem simulation. user_pref("network.proxy.http", "chainsaw"); user_pref("network.proxy.http_port", 8336);

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