User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.10) Gecko/20100914 Firefox/3.6.10 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 Every once in a while I get an email whose entire message source ends up displaying as the body of the email, and none of the headers are displayed in the Message Reader UI (they are correct in the message list though). Reproducible: Couldn't Reproduce Messages are from different senders. I know it happens when received with my GMail account (IMAP).

Attached is a diff between the displayed body and the original message source from Ctrl+U. Potentially private information was replaced with strings of X's.

A second message, from a different sender.

Does it work better in -safe-mode (http://support.mozillamessaging.com/en-US/kb/Safe+Mode) ? When this happens , any error messages in Tools -> Error console ?

(In reply to comment #0) > Every once in a while I get an email whose entire message source ends up > displaying as the body of the email, (snip) Same phenomenon as Bug 506504? (see attached screen shot)

Ludovic - Before posting this bug, I checked the error console when opening the two posted emails, and nothing showed up (no errors, warnings, or messages). WADA - This does appear to be the same as that bug. Sorry about the duplicate, but the title of that bug doesn't sound at all like how I would have described it.

Actually, reading through the comments of Bug 506504, it seems different. The screenshot matches, but the message is loaded like that right away (not after clicking anything about encoding), and switching to a different message and back does NOT fix it. Sorry about the confusion.

(In reply to comment #0) > Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4 (In reply to comment #7) > Sorry about the confusion. It's never your confusion. > Actually, reading through the comments of Bug 506504, it seems different. > The screenshot matches, but the message is loaded like that right away (not after clicking anything about encoding), > and switching to a different message and back does NOT fix it. Probably same problem as non-base64 case of Bug 572886(caused by "internal reload" due to <meta charset>), which is resolved by patch for bug 582788(patch is landed only on Gecko Trunk=Gecko 2.0. The patch prohibited unneeded "internal reload" in some cases). Check message source which produces your problem.

(In reply to comment #8) > Probably same problem as non-base64 case of Bug 572886(caused by "internal > reload" due to <meta charset>), which is resolved by patch for bug 582788(patch > is landed only on Gecko Trunk=Gecko 2.0. The patch prohibited unneeded > "internal reload" in some cases). > Check message source which produces your problem. The source I'm looking at says the following: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Is that what you mean?

(In reply to comment #9) > Is that what you mean? No. Bug 505072 is for Tb 3 and problem occurs only on HTML mail or HTML part with <meta> tag, and the bug is already resolved in Tb 3.1.0. Bugs I pointed were for next; - text/html mail or text/html part in multipart/xxx which has <meta> tag for charset speccification in HTML - text/html or text/plain in multipart/mixed, which is encoded in base64 or quoted-printable. Those bugs were problem with html5.enable=true(trunk build only issue) and with HTML mode display only. Is simple text/plain mail? Can you attach screen shot and mail data(.eml file, attach to bug, not paste).

In both the screenshot and the uploaded email, I replaced some private information. I did not change anything about the eml file except to replace certain characters in email addresses and subjects with x's. (I used a plain text editor, not a word processor).

(In reply to comment #11) > One of the offending emails. Same corruption pattern as bug 587528. Seting dependency for ease of tracking.

Confirming per attached mail data.

Offline-use=on folder? Or Offline-use=off? (Folder properties, Synchronization)

(In reply to comment #16) > Offline-use=on folder? Or Offline-use=off? (Folder properties, Synchronization) It is on.

Seth, does bringing up folder properties and clicking the repair button fix the problem?

It seems to. The emails that were garbled before look fine now. I have way too many emails in that folder to go through the entire contents to see if any that were good have gone bad.

Closing as dup to consolidate to single bug.