9985 - M8: ALT tags being displayed even when image is available.

Status: VERIFIED WORKSFORME

(Core :: Graphics: ImageLib, defect, P3)

Description

[Jordan Mendelson]

home.netscape.com is littered with 'pixel' ALT tags even though images/pixel.gif is available...

Comment 1

[troy]

Works fine for me

Comment 2

[Jordan Mendelson]

Attachment: Screenshot of bug - note the '1x1' ALT tags everywhere

Comment 3

[troy]

Noting that the URL in the snapshot is a different URL
, http://www.sprint.com/products, than the URL in the URL field of the bug
report

I just tried that URL and it loaded fine (no alt-text displayed) for me, too.
Either this is a platform specific problem, or an occasional intermittent
problem with images not loading

Comment 4

[Jordan Mendelson]

This bug is extremely sporatic, to reproduce in M8/windows & fullcircle:

1. Remove everything from cache\, del cache\*.*
2. Run apprunner -url http://home.netscape.com/
3. In the location input box, type:  http://home.netscape.com/images/pixel.gif

I get this as a result:

Doing Startup...
Creating browser app core
BrowserAppCore has been created.
Setting content window
Components = [xpconnect wrapped nsIXPCComponents]
Components.classes = [xpconnect wrapped nsIXPCClasses]
Components.classes[component://netscape/preferences] = component://netscape/pref
erences
browser.startup.page = 1
startpage = http://www.mozillazine.org/
Reading file...
Reading file...Done
Document http://home.netscape.com/ loaded successfully
Document: Done (5.82 secs)
FindShortcut: in='http://home.netscape.com/images/pixel.gif'  out='null'
Error loading URL http://home.netscape.com/images/pixel.gif
Document: Done (0.33 secs)

Note the error loading the image... but here's the odd part:

1. Clear the cache again, del cache\*.*
2. This time load the image directly: apprunner -url
http://home.netscape.com/images/pixel.gif
3. Load http://home.netscape.com/ from input location box
4. Type in: http://home.netscape.com/images/pixel.gif in the input location box

Doing Startup...
Creating browser app core
BrowserAppCore has been created.
Setting content window
Components = [xpconnect wrapped nsIXPCComponents]
Components.classes = [xpconnect wrapped nsIXPCClasses]
Components.classes[component://netscape/preferences] = component://netscape/pref
erences
browser.startup.page = 1
startpage = http://www.mozillazine.org/
Reading file...
Reading file...Done
Document http://home.netscape.com/images/pixel.gif loaded successfully
Document: Done (0.71 secs)
FindShortcut: in='http://home.netscape.com/'  out='null'
Doing Startup...
Creating browser app core
BrowserAppCore has been created.
Setting content window
Components = [xpconnect wrapped nsIXPCComponents]
Components.classes = [xpconnect wrapped nsIXPCClasses]
Components.classes[component://netscape/preferences] = component://netscape/pref
erences
browser.startup.page = 1
startpage = http://www.mozillazine.org/
Document http://home.netscape.com/ loaded successfully
Document: Done (5.87 secs)
Document: Done (3.68 secs)
FindShortcut: in='http://home.netscape.com/images/pixel.gif'  out='null'
Doing Startup...
Creating browser app core
BrowserAppCore has been created.
Setting content window
Components = [xpconnect wrapped nsIXPCComponents]
Components.classes = [xpconnect wrapped nsIXPCClasses]
Components.classes[component://netscape/preferences] = component://netscape/pref
erences
browser.startup.page = 1
startpage = http://www.mozillazine.org/
Error loading URL http://home.netscape.com/images/pixel.gif
Document: Done (2.36 secs)
Document: Done (2.63 secs)
Document http://home.netscape.com/misc/snf/popup_sit5a.html loaded successfully
FindShortcut: in='http://home.netscape.com/images/pixel.gif'  out='null'
Error loading URL http://home.netscape.com/images/pixel.gif
Document: Done (0.33 secs)

All sorts of bad stuff happens here. The output doesn't even make sense, but one
thing is for certain, the same image loaded at the beginning didn't load at the
end after home.netscape.com was in the cache.

I'm thinking cache corruption bug, possibly database problems.. maybe an image
library bug. I can reproduce this 100% of the time..

Sorry about the image being the wrong one, I'll go and make one for
home.netscape.com...

Comment 5

[Jordan Mendelson]

Attachment: home.netscape.com m8 rendering - someone needs to add image/jpeg to the "what kind of file is this" times in bugzilla... :)

Comment 6

[troy]

Sure looks like there's something worth investigating here, so I'm assigning to
Pam as an image library/network related problem

Comment 7

[pnunn]

putting on my radar.
-pn

Comment 8

[Jordan Mendelson]

I'd just like to note that this bug isn't apparent in the Linux M8. It seems it's Windows only.

Comment 9

[jkjome]

I have noticed this since at least M5.  It has always been there.  Everything
is fine for a while, but once you get this behavior, it doesn't stop.  The
cache just gets totally corrupted.  It doesn't really matter what page you go
to.  I'd consider this a decently serious bug to fix since it completely
impedes the user from viewing content.

Comment 10

[leger]

Clearing Fixed resolution due to ReOpen of this bug.

Comment 11

[pnunn]

I just went through the well documented steps (much thanks
for the very clear info.) with my current build. I can't
reproduce the problem. Keep in mind that this build has the
new netlib (necko) and subsequent bug fixes to 08-09-99.

I have a feeling that the bug existed in an earlier version, but
has been fixed by one or more checkins. The description sounds to
me like a bug I experienced, where an image file name
given w/r to a base address, the full, resolved image file spec
was incorrect.

 <img src="/images/blah.gif"> did not resolve to
http://www.foo.org/images/blah.gif

This would generate an 'image not found' condition, which would display
the image file name text as described in the bug report.

I'm closing this as worksforme.
-pnunn

Comment 12

[Chris Petersen]

With the August 11th build, I'm not seeing the original problem described. Tested
under Mac 8.6, Win 95, and Win 98.

Comment 13

[Jacob Kjome]

Ever since the first Necko release, this bug has been non-existent.  Nice to
see since it was getting very annoying.