large images not be scaled down to windows size

RESOLVED FIXED in Thunderbird 10.0


Message Reader UI
6 years ago
6 years ago


(Reporter: Bernd, Assigned: standard8)



6 Branch
Thunderbird 10.0

Thunderbird Tracking Flags

(thunderbird8+ fixed, thunderbird9+ fixed)


(Whiteboard: [good first bug])


(1 attachment)



6 years ago
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Build ID: 20110928060149

Steps to reproduce:

I send a plain text email to myself with an attachment (jpg)  of more than 3 MB.
View > Display Attachments inline is activated.
The Thunderbird window is maximized. I open the received in the message preview window or standalone message windows.
I scroll down to the bottom of the message body to see the attached image file.

Actual results:

The image is larger than the actual window and has to be scrolled horizontally.
Now I click on the max/normal button right on top. The window becomes smaller and the horizontal scroll bar disappear. The image has become the size of the window. 
Clicking again on the button maximize the window and the image is still scaled down.
Changing to another email and back again I have to do the same procedure.
It's not important if the first window is maximized or normal.

Expected results:

The image should be scaled down immediately without any other action.
It should have same behaviour as in TB 3.1 which works fine.

Comment 1

6 years ago
I forgot a word:
"I open the received email..."

Comment 2

6 years ago
Seen on Linux and Windows 7 with current release and comm-aurora builds, though not consistently reproducible. With mail.enable_automatic_image_resizing set true, large image attachments occasionally don't trigger the function in bug 372080 on initial opening of the message, only after resizing the window. However, I had some instances where the same message subsequently opened with the image fit to the window width after revisiting the same message or even when opening a message the first time, thus it's a bit fuzzy what exactly triggers this issue.
Ever confirmed: true
Keywords: regression, regressionwindow-wanted
OS: Windows XP → All
Hardware: x86 → All
Bern could you follow the instructions at and find when this regressed ?

Comment 4

6 years ago
Do you mean I have to install all beta version in between since 3.0 and check their behaviour?

Comment 5

6 years ago
I noticed another behaviour and can use it as workaround.
When TB doesn't rescale the image automatically I click on (+) to open the attachment pane, so that I can see the attachment's file name.
TB immediately rescales it.

Comment 6

6 years ago
I tested the following versions with the same  profile.
This profile has only one account, no add-ons, default theme, default settings:

3.1.17  does not have this bug
5.0     does not have this bug
5.0b2   does not have this bug
6.0     has this bug
6.0b2   has this bug
7.0     has this bug
7.1     has this bug

Comment 7

6 years ago
Regression pushlog:
Triggered by
Bug 585877 - remove document.height / document.width^[^\0]*%24&hitlimit=&tree=comm-central

doc.width should be repraced doc.body.getBoundingClientRect().width.
Blocks: 585877

Comment 8

6 years ago
(In reply to Alice0775 White from comment #7)
> doc.width should be repraced doc.body.getBoundingClientRect().width.

or (IMHO better)   doc.body.clientWidth
tracking-thunderbird10: --- → ?
tracking-thunderbird8: --- → ?
tracking-thunderbird9: --- → ?
Keywords: regressionwindow-wanted
Whiteboard: [good first bug]


6 years ago
Duplicate of this bug: 694240


6 years ago
Duplicate of this bug: 547141


6 years ago
Version: 7 → 6
I notice that the version has been changed to 6 from 7 but this still means that the bug in version 7.x will be fixed right?

Comment 13

6 years ago
(In reply to Robert "Unlogic" Olofsson from comment #12)
> I notice that the version has been changed to 6 from 7 but this still means
> that the bug in version 7.x will be fixed right?

The version update was just to reflect the point of regression as detailed in comment 6.

Comment 14

6 years ago
Actually, the correct Version would be "trunk" because trunk is affected and it has to be fixed in trunk to begin with

Comment 15

6 years ago
(In reply to j.j. from comment #14)
> Actually, the correct Version would be "trunk" because trunk is affected and
> it has to be fixed in trunk to begin with

It depends on your use of the version field. We've generally used version as the first one affected, rather than the latest version affected which is what trunk would refer to (and doesn't actually give any more information).

Comment 16

6 years ago
Created attachment 571036 [details] [diff] [review]
Proposed fix

I think this should fix it. As I couldn't reproduce it 100% I verified by looking at the attributes of the image in the document in the email via DOMI.
Assignee: nobody → mbanner
Attachment #571036 - Flags: review?(dbienvenu)

Comment 17

6 years ago
Comment on attachment 571036 [details] [diff] [review]
Proposed fix

this path wfm - w/o the patch the bug is fairly easy for me to reproduce. When I click on a message with an oversize image, I see the scrollbar. If I maximize the window, the image is scaled, and re-scaled if I restore it. It seems to be just the initial click where the resize doesn't happen.
Attachment #571036 - Flags: review?(dbienvenu) → review+


6 years ago
Attachment #571036 - Flags: approval-comm-beta+
Attachment #571036 - Flags: approval-comm-aurora+

Comment 18

6 years ago
Checked in:
and on the relbranch for 8.0 beta 4:

This will be in the beta 4 release that we should be publishing sometime tomorrow and will be available from here:

If folks can check it is fixed, that would be useful.
Last Resolved: 6 years ago
status-thunderbird8: --- → fixed
status-thunderbird9: --- → fixed
tracking-thunderbird10: ? → ---
tracking-thunderbird8: ? → +
tracking-thunderbird9: ? → +
Resolution: --- → FIXED
Target Milestone: --- → Thunderbird 10.0
You need to log in before you can comment on or make changes to this bug.