User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/20100625 Firefox/3.6.6 Build Identifier: On an IMAP server, when displaying a mail (clicking on it on the index) which has an attachment that cannot be displayed inline (for example PDF or Office document), the text part of the mail is shown, but the progress bar is stuck in an endless loop and the status line says "Downloading message..." forever. Thunderbird's CPU usage raises to about 33% (no matter if you have a slow or fast CPU, it's always about one third of the CPU). In opposite to other tickets, it's not just slow and eventually finishes, but it's totally stuck. The GUI doesn't freeze. I can even double click on the attachment and view/download it afterwards. Gloda is turned off, and offline-sync is turned off as well. Users on the net reported, it works better if both is turned on (which is the default). This bug is new in TB3 (3.0, 3.0.*, 3.1). It worked in TB2. So it might be related to Gloda/Offline-Sync. Same problem on Windows XP and Linux (Fedora 12 + 13). Doesn't seem to be related to operating system or platform. Packages downloaded from Mozilla web server. No add-ons. Happens on different IMAP accounts on different IMAP servers. Unfortunately, it doesn't happen always but only on about every second message with an attachment. Reproducible: Sometimes Steps to Reproduce: 1. Turn of Gloda/Offline-Sync. 2. On an IMAP account, have 2 messages with an attachment that cannot be display inline (so that it must be viewed with an external application or downloaded). 3. Switch between these 2 messages. Actual Results: About every second time the message text is displayed but Thunderbird 3 hangs, the progress bar loops endlessly, the status line displays "Downloading message..." and CPU usage goes up to about one third. TB 3 doesn't actually freeze. You can just switch to other message, and that might be displayed without a problem. Expected Results: No endlessly looping progress bar, no high CPU usage (for no good). Besides the energy consumption, the CPU usage is a real problem on mobile computers (batteries).
Can you go into Tools > Options (Windows) or Edit > Preferences (Linux), then Advanced > General tab and click on Config Editor; copy-paste the preference mail.server.default.mime_parts_on_demand into the search bar and double-click on it to toggle it to false; does the problem persist after restart? If it's gone now, this would by another manifestation of bug 529210.
Indeed, bug #529210 describes a very similar effect. When I change mail.server.default.mime_parts_on_demand to false, the problem still exists for viewing new messages (not displayed yet after changing the setting) but is gone for messages once they have been displayed correctly. So, with mail.server.default.mime_parts_on_demand=false the bug can no longer be easily reproduced by just continuously switching between two messages. But if I have, let's say, 20 messages with attachments that I haven't displayed after changing the config setting, chances are still high that on first display some of the messages load endlessly like described above. Regarding bug #529210, I'm wondering if changing the config setting really is a 100% reliable workaround or if it just makes it more unlikely to trigger the problem. However, it clearly shows that Thunderbird doesn't have a general problem with handling attachments because if works flawlessy if the data can be taked from the local cache (and I think that's good news ;-), but that the bug is somehow related to fetching message details from the IMAP server. What I don't understand is that it doesn't happen always. Maybe some kind of timing problem? However, it doesn't seem to make a noticable difference if client and server are in the same LAN (Gigabit Ethernet) or if the connection is slow (like dial-up or mobile service provider).
Moving to Networking: IMAP component so that it gets the attention of the right people for further analysis. Does it happen with all attachment or just those of a specific size?
Component: Message Reader UI → Networking: IMAP
Product: Thunderbird → MailNews Core
QA Contact: message-reader → networking.imap
Version: 3.1 → 1.9.2 Branch
Same issue as Bug 565852?
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a5pre) Gecko/20100504 Shredder/3.2a1pre can't repro with trunk
(In reply to comment #4) > Same issue as Bug 565852? I haven't analyzed it in full detail (like watching at the local cache files), but at least the strange LOGOUT behaviour is the same here. (I didn't notice in Thunderbird, but when looking at the IMAP daemon logfile I was surprised to see the logouts.) If this is marked as duplicate then please note that the bug is not specific to Windows XP but also happens on other operating systems like Linux. (Platform -> any) And as said, mail.server.default.mime_parts_on_demand=false doesn't really is a workaround because it only works for message in the cache, not for messages that haven't been displayed (cached) yet. It just makes the problem a little more unlikely because it no longer affects messages already seen.
To Andreas (bug opener), can you try to reproduce in a current trunk build like the just released 3.3 alpha 1? Make sure to backup your profile before trying. http://www.mozillamessaging.com/en-US/thunderbird/3.3a1 http://kb.mozillazine.org/Testing_pre-release_versions A couple of related problems have been fixed by the bug WADA refers to, and your report looks much like bug 599830. Thus, it may no longer be an problem, unless the fix for bug 565852 introduced any other performance issues.
Thanks for working on that issue. I've downloaded and installed Miramar 3.3a1 (with a copy of my current user profile for Thunderbird 3.1.6), and it looks so much better now. I could not reproduce the reported problem with 3.3a1. Suprisingly, I had the feeling that 3.3a1 handles attachments somewhat faster in general. Feels "snappier". But that might be just due to other optimizations in 3.3a1 (not related to attachments but to overall mail handling). In other words, 3.3a1 worked fine. After the test of 3.3a1, I switched back to 3.1.6 and the reported problem immediately occured again. If that fix could be extracted from 3.3a1 and back-ported to the stable 3.1 branch, that would be absolutely fantastic!
Thanks for the quick reply, I'm marking your report as a duplicate of the bug which fixed the underlying issue. It's too late for 3.1.7 now, but I left a comment hoping that it will be included for the next minor 3.1 release.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 565852
You need to log in before you can comment on or make changes to this bug.