STEPS TO REPRODUCE: Open http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2001 in Mozilla. ACTUAL RESULTS: The first time you load the page, it lays out fine. However, a reload places an IE-style "broken image" glyph with the alt text, instead of flowing it as in the first load. EXPECTED RESULTS: Once the image is found to not be available (whether during the initial flow or later on) the IMG element should be treated as a normal floating element containing the ALT text, as with non-floating broken IMG elements. The broken image glyph should _not_ be used. The results on the first load and subsequent loads should be the same. ADDITIONAL COMMENTS: The bug may be that if an image is found to not be available straight away, as may well happen if the image is cached, CantRenderReplacedContent (or whatever it's called) fails. This would explain why the first time it works (because that function is called on the reflow) but the next time it doesn't (the function may be called on the original flow). I may be totally off-base though.

Stealing QA contact. Setting milestone to M15 as bug 15545. Setting dependencies on bug 1994 (master alt text bug) and from bug 7954 (HTML compliance meta bug).

Fixed. The HTML image loader code was squelching the notification that the image load failed

Ok, this is fixed. Troy: I notice that what _actually_ happens at the moment is that we add an image frame, which displayes with the loading image glyph and the ALT text, and then decide we are not going to display that frame, and replace it with the text frame, and _reflow_ it to have the alt text display as if it was not an image in the first place. This is fine if we don't know the image is going to be displayed (modulus bug 23691), but in this case it means that we actually first lay it out with the broken glyph icon, and immediately flash to the text-frame version. Do you care? i.e., should I open a bug about this flicker, or should we just say that this is As Designed and not worry about it?

I don't care, and to tell you the truth there isn't much I can do about it. Yes we first create an image frame and it try to load the image. If the image load fails the image frame notifies the pres shell that it can't be rendered. Then the pres shell asynchronously (i.e., queues up) an NSPR event and when it processes it we call the frame construction code which creates the inline (or block) frame with the text frame child and then replaces the image frame with the new frame The reason for the async step there is that it's not really safe to synchronously discard the image frame while there's potentially code on the stack that cares. Discarding the image frame causes lots of image lib objects to get destroyed and for a while that resulted in a crash. I think the ref counting is better now and it might work, but there's no way to be sure it would work for all plugins So to be safe we have the async step and that's why the delay. The image frame could leave up the loading icon instead of displaying the broken icon, but because things are done asynchronously the pres shell can't tell it whether the frame will be discarded or not. Under normal circumstances everything will work fine and it will, but who knows for sure

Ok, that's cool.