1085677 - Inline Preview display of attached images not working (big image is not rendered until window resize)

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Jorg K (CEST = GMT+2)]

Attachment: 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.

Comment 1

[Jorg K (CEST = GMT+2)]

I tried version 31.2.0, the current "official" version at time of writing.
Version 31.2.0 does NOT show this problem.

Comment 2

[Magnus Melin [:mkmelin]]

WFM on linux trunk. Can you try a nightly? http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/

Comment 3

[Jorg K (CEST = GMT+2)]

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.

Comment 4

[Jorg K (CEST = GMT+2)]

Attachment: video showing the problem.mp4

Video showing the problem. Drag the right edge and it's OK.

Comment 5

[Jorg K (CEST = GMT+2)]

Attachment: video showing the problem.mp4

Oops, the video didn't play. Try again.

Comment 6

[Jorg K (CEST = GMT+2)]

Attachment: video showing the problem.zip

Still not playing. This time as ZIP.

Comment 7

[Magnus Melin [:mkmelin]]

Wild guess, but tried tweaking gfx.direct2d.disabled and layers.acceleration.disabled ?

Comment 8

[Jorg K (CEST = GMT+2)]

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.

Comment 9

[WADA:World Anti-bad-Duping Agency]

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

Comment 10

[Jorg K (CEST = GMT+2)]

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.

Comment 11

[Jorg K (CEST = GMT+2)]

Maybe good to get this looked at before TB38, since it's a regression. Problem persists in TB36 beta.

Comment 12

[Kent James (:rkent)]

Nobody seems to be jumping on this, so I don't think we can solve it for TB 38.

Comment 13

[Jorg K (CEST = GMT+2)]

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.