first, Look at the URL. If image file is not there and width and height is specified, Mozilla shows strange printings to me. If they're in an Anchor tag, and there's an alt element specified, the message in alt element is printed and then line-feeded. Otherwise, there's nothing from <IMG> tag. but, if I make this file in my local, and show by file://C|index.html, there was a space specified in Width and Height. Ummm... I cannot make me understood in some words, so please look. Build ID:2000022820

Ups. I think I can make the URL read when I write in a box named URL. http://www.f-o-rainbow.com/bugs/index.html this is the URL I've written in last.

Wow, that's a little weird. Confirming bug, changing component to Layout.

Ok, moving to imagelib and reassigning bug - image does not exist, width and height defined, alt="", causes "" to be shown, but width and height are overridden.

Rubbing magic lamp to invoke py8ieh genie.

Thanks Eli. Moving back to layout component. Reassigning to Troy. Stealing QA. Nominating for beta1 (see below). Updating summary. Setting milestone to M15. Setting dependencies (HTML4 and alt text bugs) and keywords (CSS1, regression). ACTUAL RESULTS Any IMG with an explicit height or width (given by either CSS or HTML) will, if displayed as a text frame due to broken links or whatnot, cause large inexplicable whitespace to appear. See: http://www.bath.ac.uk/%7Epy8ieh/m/altregression.html ...for a simpler test case. Troy: This might have been broken by your recent ALT changes (bug 24125). PDT team: I am nominating this for beta1 since it is a recent regression which used to work fine and which will make many pages look very bad if images are disabled or if they do not download in time. I would suggest a PDT- target.

No, my change for bug #24125 definitely didn't cause this problem. It was a really trivial change, and the change wasn't made until 3/13 and the bug was reported on 3/10

Yeah, I realised that that did not cause the problem when I looked at your code to comment on it in bug 24125.

Okay, I found the problem. It was a bug introduced by me evidently in revision 1.335 of nsCSSFrameConstructor.cpp The fix is immediately obvious. Since this has been broken since 1/21/00 (that would be 21/1/00 to you Ian :-) and this is the first anyone has noticed, I don't think it's something we need to worry about for beta 1

Okay, I checked in a fix

VERIFIED fixed in 2000040815 build on Win32 using http://www.f-o-rainbow.com/bugs/index.html [now 404] http://www.bath.ac.uk/%7Epy8ieh/m/altregression.html http://bugzilla.mozilla.org/showattachment.cgi?attach_id=6563