24815 - Reload causes broken glyph icon to appear

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Hixie (not reading bugmail)]

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.

Comment 1

[Hixie (not reading bugmail)]

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).

Comment 2

[troy]

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

Comment 3

[Hixie (not reading bugmail)]

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?

Comment 4

[troy]

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

Comment 5

[Hixie (not reading bugmail)]

Ok, that's cool.