31451 - explicit height and width confuse poor alternative text frame

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[YONEMURA Kaoru]

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

Comment 1

[YONEMURA Kaoru]

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.

Comment 2

[Ryan Massie]

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

Comment 3

[Doron Rosenberg (IBM)]

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.

Comment 4

[Eli Goldberg]

Rubbing magic lamp to invoke py8ieh genie.

Comment 5

[Hixie (not reading bugmail)]

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.

Comment 6

[troy]

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

Comment 7

[Hixie (not reading bugmail)]

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

Comment 8

[troy]

Attachment: Reduced test case

Comment 9

[troy]

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

Comment 10

[troy]

Okay, I checked in a fix

Comment 11

[Hixie (not reading bugmail)]

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