problems if I interrupt loading of imap message with large image

VERIFIED FIXED

Status

defect
VERIFIED FIXED
12 years ago
12 years ago

People

(Reporter: moco, Assigned: Bienvenu)

Tracking

({verified1.8.1.5})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

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

Comment 1

12 years ago
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.
Assignee: nobody → bienvenu
> The message is in my inbox, set up for online usage.

oops, yes, I meant offline usage.
Assignee

Comment 3

12 years ago
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.
Assignee

Comment 4

12 years ago
Posted patch proposed fixSplinter Review
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.
Attachment #270631 - Flags: superreview?(mscott)
Assignee

Comment 5

12 years ago
Comment on attachment 270631 [details] [diff] [review]
proposed fix

we will want this for 1.8.1.5 once it lands on the trunk.
Attachment #270631 - Flags: approval1.8.1.5?

Updated

12 years ago
Attachment #270631 - Flags: superreview?(mscott) → superreview+
Assignee

Comment 6

12 years ago
fixed on trunk - please try tomorrow's trunk build
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED

Comment 7

12 years ago
Comment on attachment 270631 [details] [diff] [review]
proposed fix

a=mscott for 1.8.1.5.
Attachment #270631 - Flags: approval1.8.1.5? → approval1.8.1.5+
Assignee

Comment 8

12 years ago
fix will be in tomorrow's 2.0.0.5-pre builds.
Keywords: fixed1.8.1.5
Assignee

Comment 9

12 years ago
I believe there are several dups out there that will be fixed by this change.
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.
I am unable to reproduce this with build version 2.0.0.5pre (20070704), so marking verified.

see spin off bug #386888.
Status: RESOLVED → VERIFIED
Seth, than you have to set the keyword not the status. ;)

Comment 13

12 years ago
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.
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
Duplicate of this bug: 384819
You need to log in before you can comment on or make changes to this bug.