At the banner spot at the top of that page, you get this strange little..what looks like a form entry spot, that says something about AREA in it. AREA is part of the anchor for our banner ad, and I think Mozilla 5 is taking it out of context... Peace, Penelope

What version of mozilla ( m4,m5, custom build ( if so what the date of the pull) are you using? I did see a problem on either the 5/10/99 build on either win32 or the mac. Changing component to parser.

I don't see anything using the 1999051108 build under Windows NT. I will mark this as worksforme within 24 hours if I don't hear back from penny. Additionally, penny may want to reread the bug writing guidelines at http://www.mozilla.org/quality/bug-writing-guidelines.html for future use. Is there a chance the image did not load? If that was the case, the source HTML reads <IMG src = "http://adserver.imaginemedia.com/cgi-bin/accipiter/AdServer.exe/AREA=PC.BET ABITES" width = 468 height = 60> - this might cause the word "area" to be displayed in the browser. If an image can't be loaded, the name of the image should be displaye, and it seems conceivable that the image name might be misinterpreted as "AREA" or "AREA=PC" - we intentionally leave off the file type (eg .GIF, .JPG) when displaying the name.

It was apparently a problem with the ad server being down for a bit. As documented elsewhere, displaying the IMG name if the image itself can't be loaded is correct behavior according to the HTML 4.0 spec... therefore this is correct behavior and won't be fixed.

cpratt: of course, now that you've learned the 'new' behaviour, those durn developers done gone and changed it back (for now): http://cvs-mirror.mozilla.org/webtools/bonsai/cvsview2.cgi?diff_mode=context&whi tespace_mode=show&subdir=mozilla/layout/html/base/src&command=DIFF_FRAMESET&file =nsImageFrame.cpp&rev1=1.76&rev2=1.77&root=/cvsroot