problems if I interrupt loading of imap message with large image I'm using tbird version 18.104.22.168pre (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.
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.
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.
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)
Comment on attachment 270631 [details] [diff] [review] proposed fix we will want this for 22.214.171.124 once it lands on the trunk.
Attachment #270631 - Flags: approval126.96.36.199?
Attachment #270631 - Flags: superreview?(mscott) → superreview+
fixed on trunk - please try tomorrow's trunk build
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment on attachment 270631 [details] [diff] [review] proposed fix a=mscott for 188.8.131.52.
Attachment #270631 - Flags: approval184.108.40.206? → approval220.127.116.11+
fix will be in tomorrow's 18.104.22.168-pre builds.
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 22.214.171.124pre (20070704), so marking verified. see spin off bug #386888.
Status: RESOLVED → VERIFIED
Not sure this is fully resolved. I'm using TBird 126.96.36.199 (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
You need to log in before you can comment on or make changes to this bug.