This is spin-off of Bug 501253 Comment #21 to 23. [Build ID] > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.4pre) Gecko/20090909 Shredder/3.0b4pre (1) Test mail of Bug 501253 was not downloaded into offline-store initially. Two text/plain mails was held in offline-store. - mailnews.offline_sync_mail=true - mail.server.serverN.offline_download=true and false - "Check for new messages at start up/every NNN minutes" = Discabled. (2-1) Display Attachments Inline = Enabled HTML is displayed at message pane, but download is executed every time. Progress meter doesn't stop. (2-2) Display Attachments Inline = Disabled. "This body part will be downloaded on demand." at message pane. (3) After a while, "xxx@yyy.zzz is up to date" appeared at Activity manager, offline-store file size is increaed, and mail data was seen in offline-store file. However, data for the mail was always removed from offline-store file by "Compact". (Attached mail folder file) 1. Short text/plain mail #1 (size=1KB) 2. Test mail of Bug 501253 (subject is altered for ease of test) 3. Short text/plain mail #2 (size=1KB) (Mail structure of test mail) multipart/mixed part-1 : multipart/related part-1-1 : multipart/alternative part-1-1-1 : text/plain(base64) part-1-1-2 : text/html (base64) <img=...> points part-1-2 part-1-2 : image/jpeg part-2 : application/pdf part-3 : text/plain

[Steps to reproduce] (0) Save attacched mail folder file to under mail directory of (dummy)POP3 account or "Local Folders". (say F-local) Create IMAP folder X-0 (keep copy of mails for test). Create IMAP folder X-1 (for test, offline-use=on) Disable offline-use option of all IMAP folders except X-1. (1) Restart Tb, copy(upload) mails in F-local to X-0. (2) Delete all mails in X-1, Compact(offline-store size=0), Copy all mails in X-0 to X-1 => file size of offline-store=2KB (3) View the test mail with "Display Attachments Inline"=Off => "This body part will be ..." (4) View the test mail with "Display Attachments Inline"=On => HTML is displayed as expected, but "downloading ..." continues. (5) View the test mail with "Display Attachments Inline"=Off => "This body part will be ..." (6) Wait for "xxx@yyy.zzz is up to date" in Activity manager. => offline-store size = 353KB (7) "Compact" of X-1 => offline-store size = 2KB

If whole mail data is downloaded by auto-sync before mail viewing, this bug doesn't occur. - Delete xxx.msf and xxx (mail folder file) - Restart Tb, click Inbox, click xxx(dont touch mail), wait for download by auto-sync (watch Activity Manager, watch file size of xxx) - After download, view mail => no problem occurs.

Same phenomenon was observed with folder of "offline use"=Off. It looks; (i) Before download of whole mail data by auto-sync: Tb behaves ad if "offline use"=Off upon mail viewing, and display problem occurs. (ii) Once (i) occurs, something in MailDB is wrongly set. (iii) After download of whole mail data to offline-store by auto-sync, downloaded data is not used by mail viewing, and (i) continues to occur. (iv) Downloded mail data is removed by "Compact" due to (ii).

thx very much for the test case.

Mail data is stored in this file upon first download with "Display Attachments Inline"=Off. Next is seen in this file. > X-Mozilla-IMAP-Part: 1.1 > Content-type: multipart/alternative; boundary="Boundary_(ID_dhQBAPeem5Om45G2cZ5jhg)" > > This body part will be downloaded on demand. --Boundary_(ID_ZiiObjgTK2fEBJgGyoAmSA)

This file was created by changing to "Display Attachments Inline"=On. After that, next phenomena ws observed. (1) Change to View/Message Body As/HTML -> HTML is rendered. "Downloading ..." doesn't disappear. (2) Change to View/Message Body As/Plain Text -> text data is displayed. (3) Change back to "Display Attachments Inline"=Off -> "This body part will be downloaded on demand" is displayed.

My suspicion here is that the partially formed message is getting into the memory or disk caches. I can't get it to go into the offline store. I'm seeing some strange issues where I can't read the message at all when offline, once it gets into the memory/disk cache.

this happened in 2.0 as well, and in 3.0, these messages can't get in the offline store this way, so we're slightly better off. I'm not going to block 3.0 on this.

It seems that the bug is somehow related to the connection speed (and therefore to some timeout). I access the same IMAP folder locally (via LAN) and remotely (via a slow Internet connection) and I have the problem only with the remote connection. The same message wrongly dowloaded by the "remote" TB, is downloaded correctly by the "local" TB. The problem has become a lot more frequent with TB 3.0; with 2.0 it happened maybe one or two times in some years, with 3.0 it happens daily. Removing the MSF file generally fixes the problem, but I can't exactly call it a bugfix. :)

Unless we become of a significant number of real users being hurt by this bug, I think we probably wouldn't block on it. blocking- set. bienvenu, feel free to set wanted+ if appropriate...

WADA, can you still reproduce this after the fix for bug 246415 landed on the trunk? It doesn't sound exactly the same, but it's similar enough to be worth checking. Thx!

"This body part will be downloaded on demand." was not observed with next build,with IMAP folder of offline use=OFF. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100213 Shredder/3.2a1pre However next phenomenon was observed. Upon open of pdf and jpeg attachment, fetch for part was issued twice. It may be affected by bug 478175.

OK, thx. duplicate fetch is a separate issue, worth its own bug, I guess.

"fetch for part was issued twice" problem may be morphed to "second attempt of fetch doesn't complete". I opened bug 565852 for it.