576194 - Attachment downloading endlessly

Status: RESOLVED DUPLICATE of bug 565852

(MailNews Core :: Networking: IMAP, defect)

Description

[Andreas M. Kirchwitz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.6) 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).

Comment 1

[rsx11m]

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.

Comment 2

[Andreas M. Kirchwitz]

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

Comment 3

[rsx11m]

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?

Comment 4

[WADA:World Anti-bad-Duping Agency]

Same issue as Bug 565852?

Comment 5

[Phil Lacy]

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

Comment 6

[Andreas M. Kirchwitz]

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

Comment 7

[WADA:World Anti-bad-Duping Agency]

xref Bug 565852 for ease of search and tracking.

Comment 8

[rsx11m]

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.

Comment 9

[Andreas M. Kirchwitz]

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!

Comment 10

[rsx11m]

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.