263244 - Alternate text of broken images not rendered in quirks mode

Status: VERIFIED FIXED

(Core :: Layout: Images, Video, and HTML Frames, defect, P2)

Description

[Gérard Talbot]

While working on a Gecko DOM Reference file, I noticed that alternate text of
broken images are not rendered if they are in table cells. In standards
compliant rendering mode, Mozilla renders alt text of broken images.

Since there are overwhelmingly more pages triggering quirks mode, I really think
this should be corrected. Among other reasons is the fact that both Opera 7.54
and MSIE 6 SP2 will render alt text of broken images in table cells in quirks mode.

I searched for duplicates and the closest I could find was comment #10 of bug
3268. No mention of such behavior at
http://www.mozilla.org/docs/web-developer/quirks/quirklist.html

Reproducible: always

Actual results:  alt text of broken images NOT rendered

Expected results: alt text of broken images rendered

Mozilla 1.8a5 build 2004100504 and Firefox 0.10.1 build 20041001 rv:1.7.3
under XP Pro SP2 here.

A very important reduced testcase, simplified demopage is coming up. One other
problem related to that testcase is that the download process (progress bar in
the statusbar) seems to never stop and the icon in the tab bar never stops
rotating, turning. That may actually be another bug.

Comment 1

[Gérard Talbot]

Attachment: Reduced self-explanatory testcase

MSIE 6 SP2 and Opera 7.54 will succeed in rendering that testcase, in rendering
the alt text of images in table cells.

There may be more than 1 bug involved in the testcase: the download progress
bar (in the status bar) never stops and the animated curved arrows icon in the
tab bar never stops.

Comment 2

[Gérard Talbot]

Okay, the download progress issue is real (progressbar never stopping) when the
file is LOCAL.
The download progressbar stops within 2-3 sec. as the page loads when I try the
testcase from bugzilla.mozilla.org. So, that part is not participating into this
bug. Sorry about mentioning all that.

Comment 3

[Erik Fabert]

And where is the difference between this bug and bug 41924?

Comment 4

[Gérard Talbot]

Bug 41924 with 200 comments is covering many issues: about size of image
placeholder for alt text, if there should be a placeholder with image
dimensions, how to render the text, input type="image", name attribute, <area
alt="..." ...>, should there be a broken image icon or not, etc.. 
The problem of this bug 263244 has been clearly defined in words and in the
testcase; the problem covered in this bug only exists in table cells and in
quirks mode as far as I can see this. Please examine again the testcase: the
alternate text of the image in the <p> is rendered while the alternate text of
the images in table cells are NOT rendered.

"When an image is used as the content of a link, specify a text equivalent for
the image."
http://www.w3.org/TR/WCAG10-HTML-TECHS/#link-text-images
After reading comment #160 in that bug and
http://www.w3.org/TR/UAAG10-TECHS/guidelines.html#tech-conditional-content
I'm sure there is a problem.
The testcase show that latest versions of Firefox (0.10.1) and Mozilla (1.8a5)
will not render text equivalent of broken images in table cells.

I read http://www.hixie.ch/specs/alttext and
http://www.hixie.ch/advocacy/alttext and "If the IMG or INPUT element has an
'alt' attribute, then the contents
of that attribute should be used as the alternate text." (Ian 'Hixie' Hickson)
clearly indicates without a doubt that there is a bug here.

Comment 5

[Errol Smith]

I do see the alt text in the testcase on both suite 1.7.3 (public) and 1.8a4
(Windows; U; Win98; en-US; rv:1.8a4) Gecko/20040927. Mozilla seems to only show
the alt text after the image request fails/times out (as you would expect). I
will grab a 1.8a5 later today to verify if this is a regression.
(btw, please add keyword "4xp" - testcase also works on communicator4.8)

Comment 6

[Gérard Talbot]

> I do see the alt text in the testcase on both suite 1.7.3 (public)

You say you see TOC PREV NEXT INDEX in the 4 cells in the testcase with 1.7.3? I
don't see TOC PREV NEXT INDEX with Firefox 0.10.1 rv:1.7.3. 

Comment 7

[Errol Smith]

Yes I do, but I have found through experimentation that this is because my
profile has "browser.display.force_inline_alttext" set to TRUE (the default is
FALSE). When TRUE, the alt text IS diplayed inside the table.
Perhaps the default should be TRUE? Maybe that preference is not applying
everywhere it should, or is applying to things it should not?
Regardless, the behaviour of ALT text inside a table is different to that
outside a table (with default settings), so this is still a bug.

Comment 8

[Gérard Talbot]

Thanks Errol for clarifying this; I never thought there could be an user pref
like force_inline_alttext.

Comment 9

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase that shows the actual problem

Comment 10

[Boris Zbarsky [:bzbarsky]]

Tables have nothing to do with this.  The image not in a table cell didn't have
a size set, and we do the quirks alt text handling only for images with a size
set.  Controlled experiments with actual controls are a wonderful thing.  ;)

I'm seeing this on current trunk.

Comment 11

[Boris Zbarsky [:bzbarsky]]

Attachment: Fix

Comment 12

[Boris Zbarsky [:bzbarsky]]

Attachment: Patch without extra hunk

Comment 13

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 161598 [details] [diff] [review]
Patch without extra hunk

The basic problem is that in this testcase the image height is smaller than the
height of our placeholder...  This patch just removes the code that bailed in
that case, since bug 78497 is long since fixed.

Comment 14

[Boris Zbarsky [:bzbarsky]]

This doesn't have anything to do with bug 41924 either.  It's certainly not
blocking it.

Comment 15

[Bill Mason]

V 20041012 PC/Win2000

Comment 16

[Boris Zbarsky [:bzbarsky]]

*** Bug 269545 has been marked as a duplicate of this bug. ***