User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.5) Gecko/2008120122 Firefox/3.0.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090101 Shredder/3.0b2pre e-ticket display total blank. changing format resets auto-detect to off. only two alternatives seem possible: totally blank page or 100% plain text of source code including plain text of graphics. Same results in preview window or separate window or tab. Prints as blank message. Reproducible: Always Steps to Reproduce: 1. book a ticket 2. get confirmation e-mail (or I could forward mine for debugging purposes) 3. try to read it or print it Actual Results: (blank) Expected Results: something I took a screen shot of the text version and saved it to a Word document. I can email that to anyone who might find it useful.

I was able to save the email to a file & open the file in Word. The only thing that appears to have not displayed/printed is the bar code. I'm not sure if it just did not print or was never downloaded.

Further research indicates all e-tickets from Delta exhibit same problem -- as far back as April, 08. e-tickets from US Air cause "display images now" button to appear. The delta confirmation does not generate this option. I can not confirm that current release of Thunderbird does or does not exhibit problem as I'm using Shredder.

Can you put the screenshot on this bug as a jpeg, png, gif, etc. (Not a Word doc though). Also try in safe mode.

does not meet definition of critical. see https://bugzilla.mozilla.org/page.cgi?id=fields.html#importance

I was able to open this file in explorer and discovered the only thing actually missing is the bar code in the upper right hand corner. I am in the process of converting the .bmp file of the text screen shot to some other more compatible version of the text display of the message file. I will post it shortly.

The original bug report stated that the only two ways the msg would display is either a blank page or text. A screen shot was taken and saved to a word document. Someone reported that a word document was not acceptable. The shot was then copied to a bmp file which was too large to email. In the mean time, I have posted the original message. Here is a gif file created from the bmp showing the text display. Also note the text in the radio type buttons in the upper right hand corner is now larger than the buttons.

I should also add that this seems at the moment to be confined to Delta only. Other e-tickets from United appear to display properly.

Have you tried to reproduce this issue in Thunderbird Safe Mode?

Results in Safe Mode identical to those previously reported.

(Remember, I'm using Shredder and not the released version of Thunderbird.)

Yes, I am on shredder as well. Can you read http://kb.mozillazine.org/Profile_Manager and create a new profile, download on of the messages, and see what happens. I forgo to ask, are you on IMAP or POP?

Since I am a POP, there is no other copy of this message to download. Server is at web site provider. I would need to buy another ticket from Delta, I think. I will try to create the new account and then ask Delta for another copy of my ticket to see what happens.

I have used the command line option to start the profile manager and created a new profile, "Test". I have it set to work off line. With this profile and shredder open, opening the saved copy of the email by double clicking causes Shredder to open the message. Moreover, it opens with legible text. Graphic pictures and icons are not displayed, but the text is legible and intelligible. Returning to the original "default" profile and repeating the file opening (while still off line) results in the error. There appears to be no way to edit or examine the "default" profile settings to see what might be different. The file folder for this profile has too many entries and I don't know where to begin. I can attach it if that would help.

Woops, added the attached file after typing in the original comment block -- original comments lost. The previously attached e-mail may either represent a different version of the same problem or a different problem. The forementioned email displayed a plain text and an attached graphic. The graphic is a single line of a spiral notebook with the ring and hole on the left edge and plain paper across the page. I believe the intent of the sender was for me to view an entire page of a spiral notebook with the text appearing to have been written thereon.

Comment on attachment 355462 [details] email w/ background not displaying Oops.

(In reply to comment #13) Bill, as I understand you, the issue has gone in a new profile (your images are not displayed because you are offline most likely, or click the show images button when you are online. If that is so, this does not seem to be a Tb issue, but likely a corruption of your original profile, either through an extension, or something else. The best thing would be to migrate everything to your new profile (except extensions, themes, etc.)make sure it works, and then reinstall your extensions (if you have any). Then you can do whatever you want with your old profile. Please do those steps first (if the problem occurs hen installing addition addons, then contact their developers). I have a feeling that this will resolve your second issue. Of course, sometimes for images to be displayed, the e-mail client has to be online and the show images button has to be clicked. Let me know how this goes.

(In reply to comment #5) > email not displayed by Shredder Mail header says; > Content-Type: multipart/mixed; boundary="----=_Part_600974_12715603.1230910647958" But there is only one text/html part, and is encoded in base64. > ------=_Part_600974_12715603.1230910647958 > Content-Type: text/html > Content-Transfer-Encoding: base64 > Content-Disposition: inline; filename=Body.html multi>1? Or multi>=1 or multi>0? Or multi>=0? Test result with Tb trunk. (1) "Display Attachments Inline" is disabled : No mail body is displayed, with any View/Message Body As setting. But the text.html part is not displayed to user as attachment. (2) "Display Attachments Inline" is enabled : Data of this part is displayed. Displayed format depends on View/Message Body As setting. Tb seems to consider the part "attachment" in some steps but consider it "not attachment" in other steps. I guess that this confusion by Tb is caused by "Content-Transfer-Encoding: base64" and "only one part in multipart/mixed". (In reply to comment #14) > email w/ background not displaying The image data is sent in next content-type. > ------_=_NextPart_001_01C96F81.502737CD > Content-Type: image/x-citrix-jpeg; AFAIK, image/x-citrix-jpeg is not image/jpeg. Are you requesting Tb to handle it as image/jpeg?

(In addition to comment #18) I checked two cases. (Case-1) additional part of text/plain is added > Content-Type: multipart/mixed; boundary="----=_Part_600974_12715603.1230910647958" > ------=_Part_600974_12715603.1230910647958 > Content-Type: text/html > Content-Transfer-Encoding: base64 > > (same as original data) > ------=_Part_600974_12715603.1230910647958 > Content-Type: text/plain > > Text data for text/plain part > ------=_Part_600974_12715603.1230910647958-- (Case-2) "Content-Transfer-Encoding: base64" is removed > Content-Type: multipart/mixed; boundary="----=_Part_600974_12715603.1230910647958" > ------=_Part_600974_12715603.1230910647958 > Content-Type: text/html > > <pre> > (same as original data) > </pre> > ------=_Part_600974_12715603.1230910647958-- Test results: (Case-1) No difference from original mail data case, except that added text/plain part was displayed as an attachment. (Case-2) text/html part was normally displayed as mail body. "Only one part" had no relation to problem. Cause was "base64 encoded mail body" only.

Response to 17. I opened shredder under "test" profile, double clicked on the saved eml which opened in shredder on line with apparent success as before. However, clicking on the icons for the missing graphics takes me to Delta's web site, or Hertz, or whoever. Since I have shredder set to check every 10 minutes for new mail, I opened under "default" profile, forwarded the message with the spiral notebook.jpg attachment and as soon as it had gone, closed shredder to reopen it in "test" and went to get mail. The mail was there without any attachment and appeared as originally displayed. I have not tried to forward the e-ticket to see if that will work. I should also add that for most emails, the display images button appears, but for both of these, there is no such option appearing. I should have warned all of you that you are always trying to "idiot-proof" the software and when you think you have it, God brings you a bigger idiot (in this case, me). I also restarted shredder in "default", disabled all plugins and either disabled or uninstalled all extensions. I'm using the default theme. Opening either of the two emails in question yields the same erroneous results. As before, opening another e-ticket, but from US Air results in the display images button appearing and once clicked, the display appears full, accurate and with all the blazing graphics one might expect to see. Response to 18. Since I don't understand it, I have no comment. Response to 19. Ditto.

(In reply to comment #20) > Response to 18. Since I don't understand it, I have no comment. See following RFCs relates to MIME. > Multipurpose Internet Mail Extensions (MIME) Part One to Five > Part One : http://www.faqs.org/rfcs/rfc2045.html > Part Two : http://www.faqs.org/rfcs/rfc2046.html > Part Three : http://www.faqs.org/rfcs/rfc2047.html > Part Four : http://www.faqs.org/rfcs/rfc2048.html > Part Five : http://www.faqs.org/rfcs/rfc2049.html I think your problem can be said; When first part of multipart/mixed(mail body in normal multipart/mixed mail) is displayable Content-Type: (such as text/html, text/plain), Tb fails to display the mail body part in mulitipart/mixed, if the mail body part(first text/html part of multipart/mixed in your case) is encoded in base64(sent in Content-Transfer-Encoding: base64). Similar problem("mail body is not displayed", but different issue from this bug) is reported to Bug 471402("multipart/related with start parameter" case). > Response to 19. Ditto. Regardless of your Ditto or not, "image/x-citrix-jpeg vs. image/jpeg" issue is completely different issue from "multipart/mixed + base64 encoding" issue. "One problem/issue per a bug" is rule of bugzilla.mozilla.org. Please open separate bug for the "image/x-citrix-jpeg vs. image/jpeg" issue, if you believe it's Tb's bug(flaw in Tb's code).

Changing summary for ease of search/understanding of problem, and confirming.

I misunderstood test results and cause of "nothing is displayed". Base64 didn't have relation to problem. Sorry for my confusion, cluttering, and spam. Problem was; If name(Content-Type:) or filename(Content-Disposition:) is specified, Tb looks to always treat a part as attachment. Then, when "Display Attachments Inline" is not checked, part is not displayed in "inline" even when the part is displayable(e.g. text/html, text/plain). This occurs even on mail body part(first part) of multipart/mixed. It seems to be regression by attachment related changes on Tb trunk. Changing summary again. To Bill Guiher(bug opener): Do you alter "Display Attachments Inline" setting? If yes, did problem of "e-ticket display total blank" occur when you set "Display Attachments Inline=No(unchecked)"? (In reply to comment #6) > This file is a screen shot of the text display from Shredder For screen shot(mail source itself is displayed as mail body): This kind of phenomenon usually occurs when ".msf" is corrupted(pointer to mail data becomes invalid). As seen in Bug 471682, Bug 472446, and Bug 471130, Tb trunk still has problems in "Rebuild Index"(re-cration of ".msf"). These problems can corrupt ".msf" content. To Bill Guiher(bug opener): Do you still see such phenomenon(mail source is displayed)? If yes, delete ".msf", restart Tb, and click the mail folder(".msf" is rebuilt). Do you see "mail source display" even after this operation?

Mail folder file contains 2 mails. Each mail has 5 text/plain parts. mail-1 : mail body(first part) has filename mail-2 : mail body(first part) doesn't have filename/name Second part to fifth part is identical. When "Display Attchments Inline"=Off, part which has name or filename is not displayed in "inline". If filename(or name) is specified in first part(mail body), data of the first part(mail body) is not displayed in attachment box. All other parts are displayed as attachment in attachment box.

Problem of Comment #23 and Comment #24 was longstanding Bug 182627. See also https://wiki.mozilla.org/Thunderbird:Fix_some_longstanding_bugs

Bug 182627 Comment #16 case was: Content-Type: multipart/mixed Content-Type: multipart/alternative Content-Type: text/plain Content-Type: multipart/related Content-Type: text/html; name="xxx.htm" with Content-Disposition: inline; filename="xxx.htm" Content-Type: image/jpeg ; End-of-multipart/related End-of-multipart/alternative End-of-multipart/mixed "name/filename in multipart/xxx part" case was not new for Bug 182627. Closing as DUP of Bug 182627.