Closed Bug 1085677 Opened 6 years ago Closed 6 years ago

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

Categories

(Thunderbird :: Mail Window Front End, defect)

33 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: jorgk-bmo, Unassigned)

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

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.
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.
Attached video video showing the problem.mp4 (obsolete) —
Video showing the problem. Drag the right edge and it's OK.
Attached video video showing the problem.mp4 (obsolete) —
Oops, the video didn't play. Try again.
Attachment #8510496 - Attachment is obsolete: true
Still not playing. This time as ZIP.
Attachment #8510498 - Attachment is obsolete: true
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Inline Preview display of attached images not working → Inline Preview display of attached images not working (big image is not rendered until window resize)
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.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.