Created attachment 8508271 [details] attachments not showing.png User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141011015303 Steps to reproduce: Sent a message with four attached images. Actual results: In the "Sent" folder, zero or one images show. It's somewhat random. They start showing if the windows is resized. Expected results: All attached images should be shown, like they used to be in TB 24.x.
I tried version 31.2.0, the current "official" version at time of writing. Version 31.2.0 does NOT show this problem.
WFM on linux trunk. Can you try a nightly? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/
Yes, I can. I tried the nightly of today, 23rd Oct. 2014. Problem persists. Some inline pictures don't show. They all show once the window is resized (for example, drag right edge a little). So seems to be a problem at first display, once the window is redrawn due to the resize, it's OK. Wanna see a video? I'll shoot you one. As I said, the problem is random. But I have a few messages with attached pictures. Typically in the one that has four attached pictures one or more don't show.
Created attachment 8510496 [details] video showing the problem.mp4 Video showing the problem. Drag the right edge and it's OK.
Created attachment 8510498 [details] video showing the problem.mp4 Oops, the video didn't play. Try again.
Created attachment 8510501 [details] video showing the problem.zip Still not playing. This time as ZIP.
Wild guess, but tried tweaking gfx.direct2d.disabled and layers.acceleration.disabled ?
Were both set to "false" by default. I set them to "true". Problem persists in 33 beta and nightly. These settings have to do with Direct2D hardware acceleration. This is not the problem here. The problem here is that the images are not rendered at all. Only when a resize event is processed, they are (re)drawn. I don't understand much about "mozilla core" or Gecko, but I could imagine that TB does all the right things, however, the underlying rendering engine is faulty. I can't imagine that anything specific needs to be happening when a window is resized.
(In reply to Jorg K from comment #0) Modified "Steps to reproduce". 0. View/Display Attched Inline = enabled 1. Attach several *BIG* jpeg image files to a simple/small text mail mail, Send Later 2. View mail in Outbox of Local Folders => If first attempt of viewing the mail, all jpeg images are sometimes rendered. But when the mail is viewed after viewing other mail, first attached jpeg image is not rendered in almost all attempt, and "Resize Window" was needed to render the image. This was observed in Thunderbird Version 35.0a1 > User Agent : Mozilla/5.0 (Windows NT 5.1; rv:35.0) Gecko/20100101 Thunderbird/35.0a1 If small PNG files or small JPEG files, phenomenon was not observed. Timing related problem? Before decompress of JPEG completes, Tb tries to render image, then rendering fails.
I'm glad you could reproduce it. I don't know how you define "big". In my case I have four pictures attached, 144KB, 151KB, 196KB and 286KB, message size is 1MB. To reproduce it, I visit the message in the "Sent" folder, but obviously you can visit it in the "outbox" folder before it's send.
Maybe good to get this looked at before TB38, since it's a regression. Problem persists in TB36 beta.
Nobody seems to be jumping on this, so I don't think we can solve it for TB 38.
As stated in comment #11, this can be reproduced with TB36 beta. However, I can't reproduce it with TB38 beta and TB39 Earlybird. So it disappeared as silently as it appeared, most likely an M-C problem.