View as plain text is not handling multipart alternative messages with a plain text alternative part - the message displays as blank. I'll attach a .eml file

you can probably reproduce this just by sending yourself a multi part message, but I haven't tried.

this asserts in mime here: MimeInlineText_parse_end (MimeObject *obj, PRBool abort_p) { MimeInlineText *text = (MimeInlineText *) obj; if (obj->parsed_p) { NS_ASSERTION(obj->closed_p, "object not closed"); return 0; }

-> me m/a in general works, see <http://bugzilla.mozilla.org/attachment.cgi?id=67192&action=view>. The problematic message here contains an m/r part within the HTML alternative. Maybe that's what causing this. I can see the bug, if I view the test msg in the browser. Does anyone know, what the assert means, i.e. what's wrong?

The message causing this problem has a vcard.

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

Note: RFC 2112 says that the type parameter in multipart/related [...] must be specified and its value is the MIME media type of the "root" body part. In the example this is text/html, which should trigger the "don't process HTML" behaviour when View > Message Body As > Plain Text is selected. Though I suggest that if the name of this view is not changed, then it really should mean "show the plain text part" (positively), not "suppress more sophisticated parts" (negatively); alternatively, the view should be called "Without advanced content" or some such. Adding the type parameter (i.e. "multipart/related; type=text/html") to my own test example doesn't make any difference currently; I have Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3) Gecko/20030312

With 1.7a-0108, Win2K, the message attached to this bug displays the plain text part with View As Plain.

I forgot how the faulty behaviour looked like. Seems to work for me. bienvenu, can we resolve this? BTW: The attached mail seems to be broken in the source already, there are HTML headers in the middle of the HTML body.

yeah, I think I fixed this.