In a new composer document, do the following: 1. click in the content to focus it. 2. Click the image button to insert an image. In the image dialog, choose a GIF image on your hard drive. Type some alt text. 3. Click OK to insert the image. Note how the image is inserted, draws once, then disappears to be replaced by its alt text. I've no idea why this happens.

odd; only happens for local gif images; local jpeg images work fine as does http://www.mozilla.org/images/mozilla-banner.gif bug in image library? Simon do you have any ideas where the problem lies?

assigning to Simon for debugging

beppe reports some more details here: 1. After inserting the image (and having it not show up), previewing the page in the browser still doesn't show the image. You have to actually quit and restart the app to show the image. This suggests to me that the image cache may be to blame. 2. What happens if you try to insert an image that is already in the image cache (e.g., view the local image in some other page before trying to insert it)? 3. What happens if you try to insert an image using JS via the DOM? Do we see the same failure patterns? I'm guessing that this bug is a problem with image loading when images are being brought in not through the normal page loading process, but as a result of dynamic insertion. Note: this bug also depends on 41924 in two ways: i) if you insert a bad image link, layout may show you nothing at all ii) the current failure mode would be more obvious if layout did show broken image icons.

Let me check the code path on this. There are also some necko cache bugs that could be murking up the view. -p

this is quite a problem and can result in needless frustration by the user. THe impression is, is that the images are not being loaded and that text is being loaded instead. Actually this has gotten worse. If I insert a local image, the image name will be displayed in the document -- without the extension. For example, if I have an image named k9.gif and select to insert that image, what gets inserted is k9. What the user sees is just that, there is no indication that it is an image, it looks like text. However, the image tag has been inserted, but as a user, you don't know that. If at this point, I select to preview, the text -- k9 -- appears but the image doesn't. If I select to open file in the browser and select that file, again just the text and no image. I have to close the application and reopen for the image to be displayed. Nominating that this be a nsbeta2+ bug

Assigning this bug to dougt@netscape.com. It looks like nsFileTransport::Process() is firing off an OnStopRequest() in the END_READ case. Necko assumes that if a stream exists and an OnStopRequest is fired, that an abort is taking place. See bug #40767 for more details.

The problem is that we set the gs->state to gif_error in gif.cpp to indicate that the image is done loading. The comment above this code: /* This is not really an error, but a mechanism to stop decoding of subsequent frames. Only the first frame is displayed for eImageAnimation_None. */ I guess this would work, but we (sometimes) trust our error code and return MK_IMAGE_LOSSAGE to the GIFDecoder::ImgDWrite which then converts it to NS_ERROR_FAILURE. Then from our transport, the OnDataAvailable() find out that there was an error and we abort. Assigning to pnunn.

Okey doke. I can see the problem now. ...since my moz build won't run, Kin has kindly offeredt the use of his machine that has a running moz build from this morning. -p

I have a fix for this. Kin tested it for me and it tests out ok. Will check in as soon as tree opens. I changed the return code so the decoding stops as desired, but an error won't trigger the error status cascade. -p

I don't think this bug depends on #41924. I'm removing the "depends on" link.

fix checked in. -p

verified in 7/25 build