A message in HTML with MIME type text/enriched gets treated as if it was text/plain when you forward it or "Edit Message as New", although it gets displayed correctly. To reproduce: - Open attached testcase in Mailnews - Hit forward or Message > Edit Message as New Actual result: The text of the message including style tags appears in the composition window. Expected result: For forward, the message should be converted to plain text if account is set to send messages in plain text, or composer should be called in HTML mode otherwise. For Message as New, HTML editing mode should be on. Linux build 2001010517 (I don't know what MUA sends HTML as text/enriched, but maybe you can tell from the headers. Attaching testcase.)

reassigning to ducarroz

Still not working with 0.9.4

Forward inline and edit as new is the same as edit draft, and for draft msg we have in MimeMultipartAlternative_display_cached_part() following lines: status = body->clazz->parse_begin(body); if (status < 0) return status; #ifdef MIME_DRAFTS if ( obj->options && obj->options->decompose_file_p && !multipart_p && obj->options->decompose_file_output_fn ) // status = obj->options->decompose_file_output_fn status = MimePartBufferRead (malt->part_buffer, obj->options->decompose_file_output_fn, obj->options->stream_closure); else #endif /* MIME_DRAFTS */ status = MimePartBufferRead (malt->part_buffer, /* The (nsresult (*) ...) cast is to turn the `void' argument into `MimeObject'. */ ((nsresult (*) (char *, PRInt32, void *)) body->clazz->parse_buffer), body); Thus we only run decompose_file_output_fn() function which only decodes message from QP/B64/etc and we do not run MimeInlineTextRichtext_parse_line() which is parser for text-enriched... I think this is common problem, not only text/enriched - it just invisible for plain text and html types, besause corresponding mime classes doesn't do much in their parsing code (just dumps it out further).

For drafts, decoded data are fed to dummy_file_write function, which just writes them to file. But we need run those data thru corresponding mime object's parsing code first...

Using this patch I successfully forwarded inline testcase. But this patch is a way far from final. There is bunch of problems with it - starting from too many |#ifdef MIME_DRAFT|s, ending with the way of choosing compose format. My strong feeling is that we need big rewrite to make it work in a "right way", but the "rightest way" would be rewrite of whole libmime in C++. Jean-Francois, do you have plans/possibility/desire/whatever to do such rewrite (of course, past 1.0)?

oh yes, I am dreaming of that every night. A nice C++ and unicode mime lib...

What stops you?

T I M E

In other words, this is not going to happen... :-(( Well, I have a couple of questions regarding the code: - do we really need all those #ifdef MIME_DRATF ? - is it possible both output_p and decompose_file_p be true at the same time? - is it possible to both output_fn and decompose_file_output_fn be defined at the same time? If the answer to last quetion is "no", then we probably can get rid of decompose_file_output_fn at all, what will make things simpler... (btw, if you ever gonna start libmime rewrite, I can help you. It's not much, but more than nothing anyway :-) )

What is this bug (and what needs to be fixed)?

This bug is about richtext not being converted on forward inline (see descr.). What need to be fixed? Libmime, I believe (see comment #6) ;-)

bug 112625 is similar to this bug

Moving to 1.0. If it's too much work to address this bug in 1.0, could you move it to 1.1 or 1.2?

Discussed at 2/19/02 bug meeting w/ Eng/PjctMg/Marketing: decided to move to 1.2, and change nsbeta+ to nsbeta-

Fixing dependency which I mis-entered on 2/20.

removing myself from cc:

The current handling (1.5, 1.7a) of the message attached to this bug is different than the original report, but still not quite useful. Forward Inline and Edit As New create an 'empty' message with an attachment (with a tempfile name) composed of only the text/enriched part of the original -- can't be edited, or even viewed in the composer, but doesn't lose the formatting when displayed inline. Since the original message has both text/plain and text/enriched parts, maybe this change is actually a regression of sorts -- perhaps originally, Forward Inline/Edit As New created a message with an text/enriched attachment *and* edited the text/plain part...? Additionally, if the original message is viewed As Plain, Forward Inline and Edit As New both load the message as plain text, with no attachment.

Resetting old milestone, updating summary in preparation for a dupe.

*** Bug 238638 has been marked as a duplicate of this bug. ***

(In reply to comment #6 from #238638) > TB displays the text/enriched part. When forwarding, that is the part that gets > used for the message body; however, since Moz/TB doesn't know how to *edit* > text/enriched, the part is treated as just an attachment to the mail. > > The forwarded mail will contain the information, and it will be seen if the > attachment is displayed inline in the recipient's client. An additional side effect is that whatever Thunderbird does (not just Mozilla Mail/News) will also make the forwarded body not viewable in several other mail programs (possibly due to the name of the attachment, in this case: file:///D|/DOCUM%7E1........TEMP\NSMAIL.1 or maybe it doesn't keep the text/enriched type.) Somehow, Outlook Express either papers over this by trying to handle everything that looks like HTML as HTML or something, because it Just Works.

*** Bug 215265 has been marked as a duplicate of this bug. ***

Richard this might have been fixed by bug 351224. Could you take a few minutes and download the latest nightly ( http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-comm-central/ ), backup your profile and test and let us know if this is fixed or not ?

Tried reproducing the bug. Composed a new mail. Inserted HTML in the mail to generate text/enriched MIME type mail.Sent the mail to myself. Received mail is displayed as it should have been. Received mail source says that the mail is a multi-part message (probably because I chose the delivery format to be rich and plain text). Content-type of the first part is text/plain. The first part contains message body without any formatting, "*" at the two ends and "/" in the middle where html tags existed in original message. Content-type of the second part is text/html. The second part contains the html tags of the original message. On forwarding message or editing message as new the message was displayed in the composer window without the html tags, with all the styles and formatting that was there in the original message. Works for me

When the delivery format is chosen as rich only the content type is text/html

TB only supports text/plain and text/html. There is no support for text/enriched according to RFC 1896 - https://www.ietf.org/rfc/rfc1896.txt. This is an enhancement request. Personally I'd close this as WONTFIX. Magnus?

Oh we have some support for text/enriched too so this is not wontfix, although maybe not likely to make much progress. Anindya: try forwarding the test case (attachment 22417 [details]). You get an attachment, not the content showing inline.

I can confirm that, but replying to the message works fine.

Terje, maybe you would be interested in this one?

May be. Will have a look at it later.