244007 - Email composed as RTF from Outlook appears completely empty

Status: RESOLVED WORKSFORME

(Thunderbird :: Mail Window Front End, defect)

Description

[Christian J. Callsen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

When I receive (TB 0.6GA 20040502, Win2K SP3+, using IMAP against an MS Exchange
Server) an email from an Outlook user who composed the email as RTF, the email
shows up correctly in the messages list with sender, date, subject, etc.

However, when I click on the message, the display in the mail message window is
*empty* (as in, all white, no body, no headers). If I select a different message
it gets displayed correctly. When I then go back and select the first (RTF)
message, the mail message window *is not updated* (so the prior message is still
displayed).

A plain RTF message with no RTF markup seems to display correctly. 

I should also notice that I've selected my IMAP INBOX to be available when offline.


Reproducible: Always
Steps to Reproduce:
1. Send a message to desired mailbox from Outlook, composing as RTF with markup.
2. Connect to mailbox and download message.
3. Select message from message list.

Actual Results:  
The contents of the message is not displayed, nor are any headers.

Expected Results:  
Either attempted to ASCII-fy the RTF, if possible, or present the message as a
single "winmail.dat" attachment like it seems the venerable Mozilla MailNews did
for some cases. I just checked with Mozilla MailNews on the particular message;
it didn't display anything either.

Brief discussion on MozillaZine Tbird-General forum is here:
http://forums.mozillazine.org/viewtopic.php?t=77690

This is the contents of such an Email from the local INBOX file. Checking with
Outlook web access, it only contains a single attachment, so there's no RTF
markup, but the email still doesn't display. 

------msg_border--
From - Tue May 18 20:01:15 2004
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
Received: by mailwest-e6
id <01C43CFC.3A9E3B10@mailwest-e6>; Tue, 18 May 2004 10:19:08 -0700
Message-ID: <A3E375FA108EF94496269A5A96AFCAC12AE27A@mailwest-e6>
From: Xxxxxxxx xxx <[e-mail]>
To: List YYY <[e-mail]>
Subject:
Date: Tue, 18 May 2004 10:19:07 -0700
MIME-Version: 1.0
Content-Type: application/msword;
name="Messaging_Tool_Console .doc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="Messaging_Tool_Console .doc"

0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAA+AAAAwh4AAAAAAAAA
EAAAxB4AAAEAAAD+////AAAAAIQeAACFHgAAhh4AAIceAACIHgAAiR4AAIoeAACLHgAAjB4AAI0e

-- end snippet -- 

Thanks for looking at this.

Comment 1

[Mike Cowperthwaite]

This header:
  Content-Type: application/msword;
indicates that the message is not RTF but rather in Word format.  Either way, 
the format of the message is proprietary -- RTF is not an open standard, and 
Mozilla does not display RTF (or Word) files inline.  If the extent of your 
problem is that the message is not being displayed, this is a dupe of 
bug 186267 (which has been, quite correctly, resolved as Invalid).

> Expected Results:  
> Either attempted to ASCII-fy the RTF, if possible, or present the message as a
> single "winmail.dat" attachment like it seems the venerable Mozilla MailNews 
> did for some cases.

The failure to see the attachment may be due to the content-type header, or not; 
the only way we'll be able to tell is to actually test on a message.  Please 
provide a (small) sample message; once the message is received, save it as a 
.EML file and attach it to this bug, using the Create New Attachment link above.

Comment 2

[Christian J. Callsen]

Agreed, however, it'd be nice if we could offer to MIME-decode email body and
save as binary? I.e., treat as if the proper MIME-headers were present?

Comment 3

[Mike Cowperthwaite]

I have a test message I obtained somewhere which has
  Content-type: image/jpeg

This displays inline (because Moz supports JPEG) but it also shows as an 
attachment, which I could save if I chose.  We need to see a test message 
showing your symptom to figure out why the body-as-attachment is not shown.

Comment 4

[Mike Cowperthwaite]

No response from reporter;  =>WFM
Christian Callsen, if you reopen, *please* attach a sample msg to this bug.