Closed Bug 692616 Opened 8 years ago Closed 8 years ago
large images not be scaled down to windows size
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.
I forgot a word: "I open the received email..."
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.
Bern could you follow the instructions at http://www.rumblingedge.com/2009/02/24/howto-find-regression-windows-through-manual-binary-search/ and find when this regressed ?
Do you mean I have to install all beta version in between since 3.0 and check their behaviour?
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.
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
Regression pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b140e7746652&tochange=c551b62cf2e8 Triggered by Bug 585877 - remove document.height / document.width http://mxr.mozilla.org/comm-central/search?string=doc.width&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central doc.width should be repraced doc.body.getBoundingClientRect().width.
(In reply to Alice0775 White from comment #7) > doc.width should be repraced doc.body.getBoundingClientRect().width. or (IMHO better) doc.body.clientWidth https://developer.mozilla.org/en/DOM/document.width
Whiteboard: [good first bug]
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?
(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.
Actually, the correct Version would be "trunk" because trunk is affected and it has to be fixed in trunk to begin with
(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).
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
Status: NEW → ASSIGNED
Attachment #571036 - Flags: review?(dbienvenu)
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+
Checked in: http://hg.mozilla.org/comm-central/rev/3162014fdc4b http://hg.mozilla.org/releases/comm-aurora/rev/da86e80a5e3b http://hg.mozilla.org/releases/comm-beta/rev/686a094bd8ad and on the relbranch for 8.0 beta 4: http://hg.mozilla.org/releases/comm-beta/rev/7760a2b833fd This will be in the beta 4 release that we should be publishing sometime tomorrow and will be available from here: http://www.mozilla.org/en-US/thunderbird/channel/ If folks can check it is fixed, that would be useful.
You need to log in before you can comment on or make changes to this bug.