40785 - Inserted image at start of document draws, then disappears

Status: VERIFIED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Simon Fraser [no longer active]]

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.

Comment 1

[Kathleen :Brade]

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?

Comment 2

[rubydoo123]

assigning to Simon for debugging

Comment 3

[Simon Fraser [no longer active]]

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.

Comment 4

[pnunn]

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

Comment 5

[rubydoo123]

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

Comment 6

[kinmoz]

Assigning this bug to [e-mail].

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.

Comment 7

[Doug Turner (:dougt)]

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.


 

Comment 8

[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

Comment 9

[pnunn]

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

Comment 10

[pnunn]

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

Comment 11

[pnunn]

fix checked in.
-p

Comment 12

[sujay]

verified in 7/25 build