The latest Linux builds don't (completely) load JPEG images, although GIFs are usually fine. Try http://developer.netscape.com, which uses both types -- the GIFs load, but not the JPEGs. This occurs regardless of whether the images are loaded as part of a page, or by themselves, e.g. http://www.netwinder.org/images/net2.jpg. Tried with nightly Linux builds from Jan 4 and Jan 8. The Jan 4 build still had a status bar, which showed that progress was stopping at 1460 out of X bytes for all the images on www.netwinder.org when I attempted to load them individually. Someone on irc.mozilla.org pointed out that 1460 is the maximum payload size of a TCP packet ... a network-related problem, perhaps? Red Hat Linux 5.1 on Pentium 166 with 64 MB RAM and Diamond Stealth 3D 2000 (ViRGE chipset, 2 MB). Running kernel 2.0.35, Window Maker 0.20.3 and XFree86 3.3.2.3

Kevin-- please reassign to someone on the linux parity rendering team.

Works fine on Mac and Win32 builds (1.8.98); adding [PP] to subject, and CC:ing myself

Note that I can only reproduce the problem described on the 1.8.98 Linux build using http://developer.netscape.com. The images on www.netwinder.org [both on root page, and net2.jpg] do load after a few seconds, but that's over a high-bandwidth connection, and I haven't been testing image rendering over low-bandwidth connectio

This is probibly a netlib problem, not a gdk one.

I'm adding gagan to the cc list.

The images don't load for me, period -- even after 10 minutes. After a few seconds, there's no network activity, and the throbber is steady at '00'. I *am* on a 28.8 kbps dial-up connection, though.

Thanks, Chad. (I've started poking around to get [or simulate] a low-bandwidth modem connection on Linux to see if this problem can be reproduced more easily on 28.8.)

This might be related to the net cache problem.

The JPEGs don't load even when set as the viewer home page via NGLAYOUT_HOME -- i.e. they don't load the first time, much less when returning to the page such that they might be cached. I don't think the current Linux builds use a disk cache (or rather, they use /dev/null) -- there's no cache directory under MOZILLA_HOME, anyway. Using the Jan 12 nightly Linux build, and setting NGLAYOUT_HOME to: http://www.netwinder.org/images/net2.jpg in several separate trials, and restarting moz after each attempt, I achieved various progress of 1460, 2920, and 4380 out of X before stopping -- again, all multiples of 1460. I also tried (several attempts each, restarting each time): http://www.linux-howto.com/images/left.jpg http://www.linux-howto.com/images/bottom.jpg http://ma.us.mirrors.freshmeat.net/images/fm07.jpg and got 1004 out of X each repeatedly.

[Thanks for the extra research! Pam is checking it out...]

This seems to work today. I'm changing to fixed. Could someone please verify?

verified in 1/26 build .....examples given are poor though.... developer.netscape.com crashes...timeout problems www.netwinder.org doesn't even have any visible jpegs on that screen.

[Since the problem specifically occured over low-bandwidth connections, I've E- mailed Chad to ask him if he'd be open to giving it a look-see, too, prior to classifying this one as formally addressed.]

sujay@netscape.com wrote: > > verified in 1/26 build .....examples given are poor though.... I'm hurt ;) > > developer.netscape.com crashes...timeout problems Hmm ... that one's new. > www.netwinder.org doesn't even have any visible jpegs on that > screen. Well make no wonder I was confused! ;) It had several JPEGs in early January when I submitted this bug, but received a makeover on Jan 21. Now there's just one GIF. Let's amend the example to, I dunno, www.jwz.org, whoever the hell that is ;) elig@netscape.com wrote: > [Since the problem specifically occured over low-bandwidth > connections, I've E- mailed Chad to ask him if he'd be open to > giving it a look-see, too, prior to classifying this one as formally > addressed.] Unfortunately (or rather, fortunately) I've traded my modem in for an ADSL connection! But I'll definitely do some more testing as soon as I get a working build. Regards, -- Chad

In the interim, I'm resetting this bug to Resolved/Fixed. Unless it's been verified over a 28.8 or equivalent connection, I don't believe we can accurately classify it as verified until that's been done. I'll reconnect with Hubert Shaw about why the Linux builds (unlike Win32) aren't reading the prefs.js file containing the proxy settings (chainsaw, 8288 will emulate a 28.8K modem). Thanks!

elig - see brenton if you need help with a 28.8 connection.

elig - see bmartin if you need help with access to a 28.8 connection.

Unfortunately, it's not the 28.8 connection, (thanks, though, Brent) --- but it's the Linux system with networking over 28.8. I really don't have the slightest clue how to set up a Linux system working outside the firewall and configure the TCP/IP & PPP settings to function accordingly, never mind getting it to authenticate my login outside of the firewall. Since it's a legitimate platform parity issue if the Unix Viewer app doesn't recognize a prefs.js file, I've been trying to get it worked out with Hubert, and will write up a [PP] bug if there's no solution by the end of the week. Thanks. --- elig the mac weenie

chadh, how does this look with latest build?

[chadh is on ADSL, so I believe he can't really verify the bug anymore, unless he has the old 28.8 sitting around in a dustbin. ;]

Yes, the 28.8 is well and truly gone. (I wept. ;) The 99-02-01 nightly Linux build dumps core on startup for me. The latest build I've been able to run is Steve Morrison's Jan 25 build from http://www.pimpmaster.org/~simeon/mozilla and that one still refused to completely load JPEGs, e.g.: http://www.jwz.org/jwz7.jpg showed progress 966 out of 11786...

Inserting Milestone info.

chadh@pobox.com, please mark this VERIFIED-FIXED if it is indeed fixed an no longer is a problem for you on latest build.thanks!

I can't verify it works over a 28.8 connection, but using the Jan 27 build that elig mailed me, I was able to get JPEGs to load over ADSL. Testing seemed to indicate the problem might be related to low-bandwidth connections, though. Anyone got a modem?

[This bug is being held open for low-bandwidth verification, per 01/27/99 comment. I'll nudge Hubie. Please leave Chad alone. Thank you. ;-]

putting elig in the qa field....we don't wanna bother chad anymore...

<3.9.99 build of Apprunner still doesn't support importing of 4.x profiles, nor is there a means to set the proxy. According to the schedule, it's not broken; just not yet implemented. I'm leaving this bug aside until the necessary functionality is present to verify it.>

Verifying as fixed to remove from radar screen, since there are a good number of "images aren't displaying properly over low bandwidth connections (see 6696 for a few).