278231 - Attachment downloaded slowly via IMAP

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[StefanB]

User-Agent:       Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040629
Build Identifier: Thunderbird version 1.0 (20041207) on Solaris 8.

I've got a large email (about 13 meg) with several large attachments on an IMAP
server. Selecting the email takes very long (as if all 13Megs were donwloaded).
Trying to open one of the attachments opens the download progress dialog and
then nothing more happens.

Opeining this email with Mozilla 1.7 (
Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7) Gecko/20040629) works fine.
Selecting the email in the first place does not take that long and the
attachment is opened properly.

This forced me to abandon TB and go back to Mozilla web suite.

Can reproduce every time with this particular email.


Reproducible: Always

Steps to Reproduce:
1.select email
2.double click attachment
3 [review].

Actual Results:  
attachment did not open

Expected Results:  
obvious

Comment 1

[WADA:World Anti-bad-Duping Agency]

Possibly similar situation to Bug 273369, timeout on POP3.
Get IMAP protocol log and attach log file to this bug(don't paste long data).
See http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap for
protocol log.
Don't forget to change "protocol:5" to "IMAP:5" when IMAP.
Please note that log file is overlayed on restart.

Comment 2

[StefanB]

Sorry, I was not patient enough.
The attachment is actually downloaded, but very slowly.
Mozilla 1.7 needs about 5 seconds to download the attachment.
When I finally get a progress bar in Firebird, it estimates
a DL time of 15 minutes (with tracing off).

The IMAP log displays a long sequence of the following while
downloading the attachment:

10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:SendData: 73 UID fetch 14625 (UID
RFC822.SIZE BODY[]<3737600.124928>)
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=0 needmore=1]
10[1fa79a0]: ReadNext10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:SendData: 73
UID fetch 14625 (UID RFC822.SIZE BODY[]<3737600.124928>)
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=0 needmore=1]
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=69 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket: * 46
FETCH (UID 14625 RFC822.SIZE 13777119 BODY[]<3737600> {124928}
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=11 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
xxxxxx-removed-xxxxxxxxx
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=78 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
xxxxxx-removed-xxxxxxxxx
Line [stream=1fa3f80 nb=69 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket: * 46
FETCH (UID 14625 RFC822.SIZE 13777119 BODY[]<3737600> {124928}
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=11 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
xxxxxx-removed-xxxxxxxxx
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=78 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
xxxxxx-removed-xxxxxxxxx
10[1fa79a0]: ReadNextLine [stream=1fa3f80 nb=78 needmore=0]
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
xxxxxx-removed-xxxxxxxxx
(...)
10[1fa79a0]: 1fa8f58:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 73 OK
FETCH completed.

The log also shows that when I first select the message, it is downloaded
completely including the attachments. When I double-click the second
attachment, the complete message is downloaded again.

Maybe this is the expected behavior but why does it take so long?
In Moz1.7 selecting the message and opening the attachment together
only takes seconds (I'm using IMAP towards MS-Exchange via LAN).

Mozilla shows a DL speed of about 770KB/s (after clearing the cache) and
about 2500KB/s when opening it a second time w/o clearing the cache.
Firebird shows 10-40KB/s when I finally get the first progress indication
after about 1 minute. (Again, tracing is off.)
While I'm waiting for the first progress indication, even the
"time elapsed" in the progress dialog does not move, so I first
thought it's completely dead.

Comment 3

[David :Bienvenu]

Stefan, I need to see the log from where the message is clicked on, i.e., the
initial fetch of the body structure. It sounds like we think all the parts are
inline. Or, did you configure thunderbird to delay marking messages read after
clicking on them?

Comment 4

[StefanB]

Sorry for the late reply, seems like a missed the notification email.

The option to delay marking as read was ON (set to 5s). Guess this
was default or converted from my Mozilla settings. Now if I switch
this option off, the message body is not displayed at all (!).
Double-clicking the message opens an empty window.
Switch delay back on, click on the message, and the body shows again.
(Some people I know have a similar problem with Mozilla 1.7.)

Here's the log from the point where I click on the email while delay
was still on:

10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:SendData: DONE
10[21087d0]: ReadNextLine [stream=210a200 nb=35 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 8 OK IDLE
completed successfully 
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:ProcessCurrentURL: entering
10[21087d0]:
1f476b8:imap.removed.com:S-INBOX:ProcessCurrentURL:imap://[e-mail]:143/fetch%3EUID%3E/INBOX%3E15985:
 = currentUrl
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:SendData: 9 UID fetch 15985 (UID
RFC822.SIZE BODY.PEEK[])
10[21087d0]: ReadNextLine [stream=210a200 nb=0 needmore=1]
10[21087d0]: ReadNextLine [stream=210a200 nb=62 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: * 21
FETCH (UID 15985 RFC822.SIZE 13777038 BODY[] {13777038}
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:STREAM:OPEN Size: 13777038: Begin
Message Download Stream
10[21087d0]: ReadNextLine [stream=210a200 nb=42 needmore=0]
(Header lines removed here for confidentiality)

10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: Date:
Thu, 23 Dec 2004 14:58:45 +0100
10[21087d0]: ReadNextLine [stream=210a200 nb=19 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
MIME-Version: 1.0
10[21087d0]: ReadNextLine [stream=210a200 nb=32 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
Content-Type: multipart/mixed;
10[21087d0]: ReadNextLine [stream=210a200 nb=51 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:     
boundary="----_=_NextPart_000_01C50779.6F7A637A"
10[21087d0]: ReadNextLine [stream=210a200 nb=2 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 
10[21087d0]: ReadNextLine [stream=210a200 nb=76 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: This
message is in MIME format. Since your mail reader does not understand
10[21087d0]: ReadNextLine [stream=210a200 nb=62 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: this
format, some or all of this message may not be legible.
10[21087d0]: ReadNextLine [stream=210a200 nb=2 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 
10[21087d0]: ReadNextLine [stream=210a200 nb=41 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
------_=_NextPart_000_01C50779.6F7A637A
10[21087d0]: ReadNextLine [stream=210a200 nb=27 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
Content-Type: text/plain;
10[21087d0]: ReadNextLine [stream=210a200 nb=23 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:     
charset="iso-8859-1"
10[21087d0]: ReadNextLine [stream=210a200 nb=2 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 
(Body part removed here for confidentiality)

10[21087d0]: ReadNextLine [stream=210a200 nb=41 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
------_=_NextPart_000_01C50779.6F7A637A
10[21087d0]: ReadNextLine [stream=210a200 nb=35 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
Content-Type: application/msword;
10[21087d0]: ReadNextLine [stream=210a200 nb=30 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:     
name="removed.doc"
10[21087d0]: ReadNextLine [stream=210a200 nb=35 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
Content-Transfer-Encoding: base64
10[21087d0]: ReadNextLine [stream=210a200 nb=34 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
Content-Disposition: attachment;
10[21087d0]: ReadNextLine [stream=210a200 nb=34 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:     
filename="removed.doc"
10[21087d0]: ReadNextLine [stream=210a200 nb=2 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket: 
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAABAEAAAAAAAAA
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
EAAABgEAAAEAAAD+////AAAAAAEBAAACAQAAAwEAAP//////////////////////////////////
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
////////////////////////////////////////////////////////////////////////////
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
////////////////////////////////////////////////////////////////////////////
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
////////////////////////////////////////////////////////////////////////////
10[21087d0]: ReadNextLine [stream=210a200 nb=78 needmore=0]
10[21087d0]: 1f476b8:imap.removed.com:S-INBOX:CreateNewLineFromSocket:
////////////////////////////////////////////////////////////////////////////

Comment 5

[Rob Hudson]

I think this is related.  Testing Thunderbird 1.1 alpha 1.

I sent myself an avi file this morning from home to have at work.  The file size
is 2MB.  When I click on the message it appears to download the message plus
attachment (the progress bar in the lower right of the window slowly inches
across).  But if I right click on the attachment to save it, it downloads it again.

The message was sent with Thunderbird 1.0 and received with 1.1.  It seems like
thunderbird downloads it twice.

Comment 6

[Joseph William Baker]

I'm concerned about Thunderbird's retrival of IMAP attachments.  I'd like to be
able to configure Thunderbird to only retrieve the text of a message, then to
optionally load inline graphics and such later.  I have a user who connects via
a 56k cell phone connection.  Because of the delays I'm seeing reported above
and a real world example when I retrieve voice mail attachments, I'm beginning
to wonder if Thunderbird could be much further improved in this area.  The voice
mail message takes a long time to display verses other messages which display
immediately.   I'll check with my email provider to see if attachments are
scanned when Cyrus IMAP daemon delivers the attachments.  However, the expected
behavior from Thunderbird should be that the attachments are never loaded unless
called for by the user.  Even Inline images should not be loaded if the
preference "View -> Message Body as -> Plain Text" is selected.  Which this
preference set, I notice a long delay when bringing up the voice mail message. 
After the message has been retrived, and I move to another message, then return
back to the voice mail message, it appears instantly.

Comment 7

[David :Bienvenu]

if you turn off view | display attachments inline, we should just download the
msg structure and body and not the (inline) attachments, for messages over a
certain size...

Comment 8

[StefanB]

I tried turning off attachments|inline with TB1.0.2
(the latest version available here).
The symptoms are the same as described in the original report.

Comment 9

[StefanB]

Re-checked this with TB 1.5 on Solaris 8. Looks better now.
Attachment download seems to be at same speed as with
Mozilla 1.7.x.

Only when I initially select a large email (13meg) it takes
somewhat longer until the mail is displayed. Here is the
comparisson with Mozilla:


Select email: TB=1:15min, MOZ= 0:45min
Open attachment: TB = MOZ = 1:55min

I think this bug should be resolved to FIXED.

Comment 10

[Ray Booysen]

Closing as WFM as no code was identified that fixed the bug.