386514 - problems if I interrupt loading of imap message with large image

Status: VERIFIED FIXED

(Thunderbird :: General, defect)

Description

[(not reading, please use [e-mail] instead)]

problems if I interrupt loading of imap message with large image

I'm using tbird version 2.0.0.5pre (20070630) on windows XP with mail.meer.net as my imap server

The message is in my inbox, set up for online usage.  The message is big (4 mb) with an image attached.

If I select the message and switch to another before it is done loading, when I switch back to the big message, it shows up as blank.  (I get the right headers in the header pane, but nothing in the message body.)

Note, even after restarting tb, the message I interrupted won't load.

But once I am in this state, if I rebuild the index on the inbox and try again (re-select the big message), we will load it (as long as I don't interrupt it).

David, I can give you my username / password if you want to try it out under the debugger.

Comment 1

[David :Bienvenu]

I'm guessing you've got your inbox configured for offline use? If so, I suspect we're marking the message as being available for offline use even though we didn't finish loading and storing it for offline use.

Comment 2

[(not reading, please use [e-mail] instead)]

> The message is in my inbox, set up for online usage.

oops, yes, I meant offline usage.

Comment 3

[David :Bienvenu]

I see a little more what's going on.  This is what we call pseudo-interruption; you click on one large message; we fetch it in chunks, and when you click on the second message, we "pseudo-interrupt" the first fetch, i.e., we stop fetching chunks of the first message, and start fetching chunks of the second message. What's happening is that when we've finished with the second message, the imap thread tells the ui thread that it's done fetching the message, and the ui thread code is supposed to mark the currently downloaded message as being stored in the offline store.  But the ui thread seems to think it's still downloading the first message, and marks it as being in the offline store. So the wrong message is marked as available.

On the trunk, I'm also seeing that we're dropping the connection in this scenario, which completely defeats the purpose of pseudo interruption. I'm not sure if that's involved with this bug, or if it's a trunk only problem. My guess is that the doc loader is killing our url.

Comment 4

[David :Bienvenu]

Attachment: proposed fix

when aborting a message download, we need to clear m_offlineHeader so that when we start downloading the next message, we'll know to set up a new m_offlineHeader.

Comment 5

[David :Bienvenu]

Comment on attachment 270631 [details] [diff] [review]
proposed fix

we will want this for 1.8.1.5 once it lands on the trunk.

Comment 6

[David :Bienvenu]

fixed on trunk - please try tomorrow's trunk build

Comment 7

[Scott MacGregor]

Comment on attachment 270631 [details] [diff] [review]
proposed fix

a=mscott for 1.8.1.5.

Comment 8

[David :Bienvenu]

fix will be in tomorrow's 2.0.0.5-pre builds.

Comment 9

[David :Bienvenu]

I believe there are several dups out there that will be fixed by this change.

Comment 10

[(not reading, please use [e-mail] instead)]

note, david tells me that you need to rebuild your index (which you can do through the folder properties dialog) after getting this fix, to verify it.

Comment 11

[(not reading, please use [e-mail] instead)]

I am unable to reproduce this with build version 2.0.0.5pre (20070704), so marking verified.

see spin off bug #386888.

Comment 12

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Seth, than you have to set the keyword not the status. ;)

Comment 13

[Peter Barwich]

Not sure this is fully resolved. I'm using TBird 2.0.0.6 (20070728) and am losing more than half of a 3.5M picture in IMAP. POP works fine (left on server), OE 6 works fine, ArgoSquirrel webmail works fine, Argo Software's own web server works fine. (Argosquirrel is a modification of SquirrelMail designed to work with the Argo software mail server) Rebuilding TB's index (folder/properties) makes no difference. Looking at message source and then opening the resultant txt file with Winzip gives a curtailed picture if done from the IMAP folder; OK with the POP folder. Looking at the file on the server directly gives a full picture.

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Peter, this is another issue. Please file it as a new bug (please cc me), describe your steps briefly  and attach an IMAP log.

http://www.mozilla.org/quality/mailnews/mail-troubleshoot.html#imap