User-Agent: Build Identifier: Mozilla Thunderbird 0.5a (20040120) There is message body text in message (visible when look message source), but doesn't show up in message window. Same message was working correctly with version 0.4, but with 0.5a doesn't. Reproducible: Didn't try Steps to Reproduce: 1. 2. 3. This it might something to do with CR/CRLF's.
Could you please attach the source of the message as a text file attachment?
This bug is hard to reproduce. This only appears on IMAP folders on only one ISP, and only seen when charset is set to iso-8859-1. If changed to UTF-8 body is seen again, but then extended characters aren't showing right. Same message from same ISP via pop3 works fine, so I really think that this is more like issue in ISPs IMAP... Message was cut usually on some (random?) location where some extended character (äöÄÖ).
Message body text missing: Source code indicates the following: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit It is appearing from what I suspect is an automated order status email vice hand sent. The text will reappear (sort of) it going to the Thunderbird view menu, selecting character encoding, then auto0detect and finally clicking on the "NO" radio button, or going to view source. If you like I can forward the message to you or cut & paste the source here. Also I am using WinXP as my OS with SP2 installed, vice Win 2000 as the original report. Thanks Bob fitzsimmonsrobert @charter.net
I *THINK* I am having the same problem on my Mac OSX 10.2.8, Thunderbird "version 1.0.6 (20050716)". I received the following junk mail (some personal details removed) which shows no content. If I switch from "auto-detect character-encoding OFF" to "auto-detect character-encoding Japanese" (for instance) the content appears, albeit poorly formatted. Switching back to "a-c c-d OFF" makes the content disappear. I figured out that there WAS content because I am still evaluating Thunderbirdd, so I'm still shadowing my email receipts with Mac's "Mail" program, v. 1.2.5 (v553)". The content shows up there. Here's the message: X-Account-Key: account2 X-UIDL: 1125159576.18412.273.xxxxxx014,S=1278 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Received: from xxx.xxx.xxx.xxx (xxx@[xxx.xxx.xxx.xxx]) by xxx.xxx.xxx.xxx (8.12.11/8.12.11) with SMTP id xxxxxxxxxxxxx for <eddiec@MA'AM_starMA'AM_archerMA'AM_.com>; Sat, 27 Aug 2005 12:19:33 -0400 Date: Sat, 27 Aug 2005 12:19:29 -0400 X-Message-Info: 657zfkFxsxT24KKifsi311pBCUoK63SPZ04kMRouO994 Received: from xxxxxxxx.xxx (104) by xxxxxxxxxx.xxxxx.com with Microsoft SMTPSVC(5.0.2195.6824); Sat, 27 Aug 2005 11:12:54 -0600 Received: from xxxxxxx.xxx (127.0.0.1) by xxxxxxx.xxx (SMTPD32-7.12 ) id D3X433; Sat, 27 Aug 2005 14:09:54 -0300 Subject: evaluate this From: firstname.lastname@example.org To: eddiec@_NOSPAMMA'AM__star_NOSPAMMA'AM__archer_NOSPAM_MA'AM_.com Message-Id: <04586781.Q017@xxxxxx.xxxx> Content-Type: multipart/alternative; boundary="--7401296653521718222" ----40149039107763552 Content-Type: text/plain; Content-Transfer-Encoding: 7Bit CellBand offers a unique way to carry your cell phone and other devices while you work and play outdoors. Take a look at our website loc\ ated at " http://www.cellband1.us " You will be glad you did! ----7995818912782409457-- ----7401296653521718222--
I've noticed a similar problem with a multi-part mime message containing embedded images and a text attachment when connecting to an IMAP server. In mime this gives: multi-part: mixed --- multi-part: related --- multi-part: alternative - for the p/t and html parts --- p/t content --- html content --- img contents - for the related parts --- txt content - for the text attachment When the message is first viewed from the server in either text or html format, without 'show attachments inline' set, the message window is blank. When viewed with attachments shown inline, both the text and html formats work fine. It appears as though the message download from the server is not happening unless 'show attachments inline' is set. No such problems occur in POP3 mode. email@example.com
Created attachment 220918 [details] Message Body example, which can't be displayed Neither Thunderbird 1.0.7-1.1.fc4 (Redhat Linux), Thunderbird 1.5.02 (Windows XP) nor SeaMoneky 1.0 (Windows XP) is able to display the attached message body. MS Outlook does ! All of the 3 above display the attached gif-file, the message text is missing !!
(In reply to comment #5) > I've noticed a similar problem with a multi-part mime message containing > embedded images and a text attachment when connecting to an IMAP server. In mime > this gives: > > multi-part: mixed > --- > multi-part: related > --- > multi-part: alternative - for the p/t and html parts > --- > p/t content > --- > html content > --- > img contents - for the related parts > --- > txt content - for the text attachment > > When the message is first viewed from the server in either text or html format, > without 'show attachments inline' set, the message window is blank. When viewed > with attachments shown inline, both the text and html formats work fine. It > appears as though the message download from the server is not happening unless > 'show attachments inline' is set. > > No such problems occur in POP3 mode. > > firstname.lastname@example.org I can confirm that this is still happening in 188.8.131.52. It seems that MS Outlook is quite good at generating these problem e-mails with "no body".
I'm having a similiar problem. I'm an IT officer for a university and a couple of our academics are experiencing the same problem, but only if the mail is sent from outlook. The mails are internal. The body of the message cannot be seen, and if reply is hit, you still cannot see the message body. If you forward the email to yourself, you can then seen what was written. I have a funny feeling this is also to do with formatting. The email were formatted in outlook, and contained text formatting of pargraphs, headings etc. Perhaps this is the problem?
I've seen this for a while. (Using Win98SE) I thought it might have been the Perl module I was using. So I loaded Mozilla Mail to check, same problem. When the mixed message of HTML and encoded Excel attachment does not display: a) pressing forward message shows the entire contents and attachment b) looking at message source then closing the popup, sometimes causes the message to be displayed correctly Here is the header info from the mail created with MIME::Lite. X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Content-Transfer-Encoding: binary Content-Type: multipart/related; boundary="----=_NextPart_000_514A_01C6A8DE.E3A97EE0" MIME-Version: 1.0 X-Mailer: MIME::Lite 2.117 (F2.6; A1.59; B3.01; Q3.01) FILETIME=[3E9B3110:01C6A900] This is a multi-part message in MIME format. ------=_NextPart_000_514A_01C6A8DE.E3A97EE0 Content-Disposition: inline Content-Length: 105529 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="iso-8859-1" <HTML><BODY><H2> :::: </BODY> </HTML> ------=_NextPart_000_514A_01C6A8DE.E3A97EE0 Content-Disposition: attachment; filename="FILE.xls" Content-Transfer-Encoding: base64 Content-Type: application/vnd.ms-excel; name="FILE.xls" 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAOwADAP7/CQAGAAAAAAAAAAAAAAAB :::
I generated this message mostly by hand, and I'm pretty sure it's correct, but Thunderbird 2.0 doesn't render the text/plain part when View -> Message Body As -> Plain Text is selected. It just shows a blank page. If I remove the multipart/related section and replace it with straight HTML it works fine obviously, as this is the common option. From: "Matthew Allen" <email@example.com> Subject: Martin's 3rd Birthday Party Invite MIME-Version: 1.0 Content-Type: multipart/alternative; Boundary="----=_NextPart_144E783A.00001608" ------=_NextPart_144E783A.00001608 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii" Hi guys, Attached is the official invite to Marty's 3rd bday picnic BBQ, love to see you there... :) Much love, Mags (+the rest of the Mallens) xx ------=_NextPart_144E783A.00001608 Content-Type: multipart/related; Boundary="----=_NextPart_144E783A.html" ------=_NextPart_144E783A.html Content-Transfer-Encoding: 7bit Content-Type: text/html <html> <body> <img src="cid:Invite.jpg"/> </body> </html> ------=_NextPart_144E783A.html Content-Type: image/jpeg; name="Invite.jpg" Content-Transfer-Encoding: base64 Content-Id: Invite.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAHgAA/+4ADkFkb2JlAGTAAAAAAf/b AIQAEAsLCwwLEAwMEBcPDQ8XGxQQEBQbHxcXFxcXHx4XGhoaGhceHiMlJyUjHi8vMzMvL0BAQEBA [snipped] H+Inhtx24P8AuYP8RQHKi6vDbjtwf9zB/iJ4bcduD/uYP8RUHovJP8K7+0z3OXqF5zyhbyQR3QeW HM5lN3IyTYHbd251F6NQqCIiAIiIAiIgCIiAIiIAiIgCIiAIiIAiIgP/2Q== ------=_NextPart_144E783A.html-- ------=_NextPart_144E783A.00001608--
Hi, it appears to be connected to IMAP. We keep getting this problem with several messages. Though, saving the messages as an .eml file and then opening the .eml files with Thunderbird always shows the message text as expected! (running TB 184.108.40.206 on Windows XP) Injecting the saved .eml back into the IMAP server shows the same behaviour, so the message is not modified at saving, thus it must be connected to IMAP directly (methinks :-) . I tried to disable mail.imap.mime_parts_on_demand, but no difference. All of the affected messages have an html part, and one image in the html part (mostly in the signature, aaarrgh!). Even when switching to plain-text view, the message text is not displayed! (Enabling display-attachments-inline is a workaraound, but not useful.) Though, f.i. MS Outlook displays these messages correctly. We would be very pleased if this could be fixed. This bug is imho very bad, since recipients really *miss* information: As some people or platforms keep sending emails containing just an attachment without any text, the error is *not* obvious to the recipient - so they just open the attachment and discard the message text (this already happend, in business use, quite embarassing). I will post a truncated sample message. Kind regards, Philipp
Created attachment 264882 [details] Truncated sample message I tried to truncate what is not necessary - also the header is not complete. The original message showed the bug, 100% reproduceable.
Attachment #264882 - Attachment description: Truncated sample message (Philipp) → Truncated sample message
I am seeing this bug occasionally. I am running version 220.127.116.11 with an IMAP server. Most times, I can recover by deleting the e-mail, going into a web-mail program and marking the message "undeleted" and "new", then going back to Thunderbird for "Get Mail", but this does not work every time.
This seems to be happening more often since 18.104.22.168, HTML emails seems to be cut at random points, I've seen the same email stop a different places when thunderbird is closed and reopened. Also when using reply, the compose pane can also stay blank and become non responsive.
Yes it seems to be more frequent in 22.214.171.124. But, in the cases I noticed, the message body always became visible, as soon as I pressed the reply button. What I do notice frequently is that MIME (de-)encapsulation seems to be confused, when I try to open an attached eml file in a message (often found in error-reports sent from various MTAs): It is often not possible to open the attached eml, or (if opening the eml works) the menu option to display its source is greyed out. My *suspicion* is that there is some problem in thunderbirds MIME decoding, which prevents thunderbird from finding attached inline images - and thus thunderbird stumbles when trying to display the message body. (Perhaps this is not a bug, rather a kind of stolidity regarding encapsulation mistakes in the received messages. Though, no difference for the user.)
running Thunderbird 126.96.36.199 Yesterday I lost (silently & all of a sudden) all the body of my Inbox e-mails from 1pm yesterday (several thousand) back to when I installed Thunderbird last February. Subfolders are ok. The Subject Headings were all there, but there was no body to the e-mails. New e-mails (after 1pm yesterday) are ok. On compacting the folders all the headings were lost and I only have the new e-mails left. The same problem occurred last February when I was running Netscape 7.0 Mail (which caused me to migrate to Thunderbird) when we also lost all our old Inbox e-mails (about a gigabyte of e-mails). This appears to be a long-standing bug in Mozilla/Thunderbird and is quite devastating. My workaround is to filter all incoming e-mails from Inbox to a subfolder. Hopefully this works.
Using latest Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:188.8.131.52pre) Gecko/20090924 Lightning/1.0pre Shredder/3.0pre ID:20090924031806 opening attached testcase "Message Body example, which can't be displayed" I have a crash (Id: 478b895e-d82c-40c5-bf9b-6ebec2090925) Wayne any idea?
(In reply to comment #18) > Using latest > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:184.108.40.206pre) Gecko/20090924 > Lightning/1.0pre Shredder/3.0pre ID:20090924031806 > > opening attached testcase "Message Body example, which can't be displayed" I > have a crash (Id: 478b895e-d82c-40c5-bf9b-6ebec2090925) Can't find the crash ? weird.
(In reply to comment #20) > It is here > http://crash-stats.mozilla.com/report/index/478b895e-d82c-40c5-bf9b-6ebec2090925 cool. so we have a testcase for bug 518686
Severity: normal → major
Component: Mail Window Front End → MIME
Product: Thunderbird → MailNews Core
QA Contact: front-end → mime
Status: UNCONFIRMED → NEW
Ever confirmed: true
Cool indeed, but there doesn't seem to be a dependency relationship between the two bugs.
No longer blocks: 518686
The issue as I saw it seems to be resolved with Thunderbird 3! Though I am not sure whether we are all talking about the exact same bug...
Thanks Philippp. Two issues, which testcase was used, and what dated+version of thunderbird 3 did you use (help|about)? And, is it same testcase used in comment 18? (see bug 518686 comment 4)
Well (quite blatantly trivial) I just openend two of those problematic messages from our production environment here after installing TB 3.0, and they now show correctly (while they still show as empty with TB 2.0.23). So my test is not against the filed testcase - I probably would not close this without at least a second opinion...
Created attachment 8374656 [details] message without text This email does not show up any text in the Thunderbird main window, although the email source confirms that the text is there.
Comment on attachment 8374656 [details] message without text This problem appears at least on my Thunderbird 24.3.0, ENG, Windows 7 64 bits.
The source of the last message is this: multipart/related + multipart/alternative ++ text/html [This part has gobs and gobs and gobs of data] ++ text/plain [this is empty] + application/octet-stream + image/jpeg + image/jpeg Whoever coded the program that generated this message is an idiot and needs to learn how MIME works, because there's at least two glaring issues. It appears to be that the author tested it only with Outlook, which displays the text (because it doesn't process MIME correctly), and therefore assumed it must work everywhere. Although this is also more fuel for my opinion that we should stop caring about the order of parts in a multipart/alternative and instead care about the Content-Type. Unfortunately, I don't think it's feasible to make these kinds of invasive changes to our current libmime infrastructure.
Dear Joshua, I agree with you, but the problem is that there may be a lot of idiots that use Outlook to send messages and we (with Thunderbird) are not able to read them. So, at the end of the story, for most of the people it looks the idiot is me, who is not able to read the messages that everybody else can read :-(
I hope there are still people here maintaining TB. Failure to display message bodies in the Body pane seems to happen in TB 24.6.0 in Windows 8, but only after I experimented with various TB display options. The normal window title is also missing. This has nothing to do with formatting on either Outlook or TB, since clicking on a folder in the folder pane, then any message listed in the Messages pane (with column headings) highlights the folder and message, but fails to show the body in the Body pane. To see the body, one must now double-click the message line in the Messages pane. I think the problem is that something I did in my TB experimenting made the auto-download or auto-display feature stop working, regardless of message content. I was unable to retrace my steps enough to fix the problem. I emphasize that this is new behavior; TB worked correctly for me for several months prior to my experimentation today. Is this the same bug or do we need a new bug report?
Problem cause is experimenting with different layouts (Menu > View > Layout > ...) Problem is empty message pane until TB is closed and reopened. Hope this helps someone.
Bruce and I are clearly encountering different bugs with a similar symptom. In his case, he is able to offer a test file to replicate the symptom. In my case, I am able to offer a user input sequence that replicates the symptom. For those interested in this symptom (an empty message pane in the standard view), please note there are many bug reports here of empty text pane contents. They are not necessarily all describing the same bug. And some of the bug reports, like this one, are mixing two or more bugs together. It might be useful for someone to analyze all the bug reports for this one symptom and sort out all the comments into a unique and exclusive set of bug reports that don't overlap. This would make fixing the bugs easier for those who have the time to delve into TB source files.
(In reply to Joshua Cranmer [:jcranmer] from comment #28) > Although this is also more fuel for my opinion that we should stop caring > about the order of parts in a multipart/alternative and instead care about > the Content-Type. Unfortunately, I don't think it's feasible to make these > kinds of invasive changes to our current libmime infrastructure. which jsmime bug# gets us there?
(In reply to Wayne Mery (:wsmwk) from comment #35) > (In reply to Joshua Cranmer [:jcranmer] from comment #28) > > Although this is also more fuel for my opinion that we should stop caring > > about the order of parts in a multipart/alternative and instead care about > > the Content-Type. Unfortunately, I don't think it's feasible to make these > > kinds of invasive changes to our current libmime infrastructure. > > which jsmime bug# gets us there? I don't have any bug on file for that portion yet; it's still only in my mental planning and design stages.
This is a follow up to my posting above on: 2014-07-19 13:13:39 PDT. First, thanks to David for his comments. After reading them, I spent a couple hours searching TB's bug database in August, with the intent of categorizing the bugs related to my symptoms and maybe taking a first step toward doing what he suggested in this comment: "sort out all the comments into a unique and exclusive set of bug reports that don't overlap". Unfortunately I became overwhelmed and gave up (also busy with other work), due to my unfamiliarity with the inner workings of TB as well as my unfamiliarity with the inner structure of email messages. My apologies to all for my lack of follow through. Secondly, after much more thought, several more occurrences of lost body text, and some more testing, I think I have located the source of my problem. I am currently using Iolo System Shield 4 as an anti-virus solution. There are two parts to Iolo's AV: real-time protection and email protection. When I turn off the email protection, my body text and embedded images are visible. Turning the real-time protection on or off does not seem to affect the email behavior. I think the bottom line to my problem, is that the Iolo AV is erroneously removing text & images from my email messages as they are downloaded from the server to the client. I will run for a few weeks without email AV scanning to see what happens, but I feel pretty certain that this is not a TB issue. Thirdly, thanks to all the people who have made Thunderbird what it is today. All your hard work is appreciated!
Bruce, Don't worry about being overwhelmed. I'm sure someday all of TB's bugs (I've found others) will be found and fixed. Thank you for your wonderful story of finding what caused your missing message bodies. The bugs I've encountered are definitely the exception; TB is a marvelous product, and I've learned to customize it to meet my needs very nicely. I, too, appreciate everyone's hard work to give TB continuing life in a world filled with poor alternatives to TB.
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
Attachment 220918 [details] displays fine. Attachment 264882 [details] displays fine. Attachment 8374656 [details] displays fine, as per comment #23 the plain text part is empty. Attachment 8459209 [details] displays fine. Tested in TB 58 Daily, but should be the same in TB 52 ESR since to my knowledge all MIME improvement we've made were uplifted. I see no need for action here. If you have problems with another message, please file another bug, this bug here is not actionable.
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.