6220 - image fails to paint when loaded in frameset doc over 56k modem (connecting at 45kbps)

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[ekrock's old account (dead)]

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.

Comment 1

[don]

Chris, who gets this kind of performance bug?

Comment 2

[chris hofmann]

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

Comment 3

[ekrock's old account (dead)]

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

Comment 4

[Warren Harris]

Deferring until after necko landing.

Comment 5

[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 6

[chris hofmann]

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

Comment 7

[Paul MacQuiddy]

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

Comment 8

[ekrock's old account (dead)]

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.

Comment 9

[leger]

Clearing FIXED resolution due to reopen.

Comment 10

[Paul MacQuiddy]

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.

Comment 11

[leger]

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

Comment 12

[Warren Harris]

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.

Comment 13

[leger]

paulmac, please check this.  Moving to m11

Comment 14

[Paul MacQuiddy]

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

Comment 15

[leger]

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