From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1a) Gecko/20020611 BuildID: 2002061104 Someone please tell me if I've missed the option to set this.. but I can't find it anywhere. I did TRY and find out before posting this bug. If I receive a multipart mime message with two parts - text/plain and text/html (which describes most emails these days), mozilla prefers to display the text/html version. There seems to be no way, other than viewing the document source, to view the text/plain portion. I have several email messages that contain the message content in the text/plain section, and an HTML signature by itself in the text/html section. When viewed in mozilla, the message that the sender wanted to say never displays because I only see the HTML .sig. I guess it could be argued that it is up to the composing email system to put the same data into both versions of the email, but this obviously can't be guaranteed. What I'ld like to see is a preference option that determines whether mozilla prefers to display text/html or text/plain when it finds messages with both. It would be great if both sections showed in the attachment list when there was more than one mime section in the message - that would make it easy to change the mime section being shown. Reproducible: Always Steps to Reproduce: Receive a multipart mime email message. Try and view each mime part without resorting to viewing the document source.
what about view\Message Body\Text Plain ?
Summary: No obvious (any?) way to view text/plain mime portion without viewing doc source → No obvious (any?) way to view text/plain mime portion without viewing doc source
Doh.. Thank you ! :) Couldn't see the trees for the forest. Could we maybe get that "view message body as ..." menu added to the right mouse button menu when clicking on a message ?
Are these multipart/alternative messages? Or multipart/mixed?
Content-Type: multipart/mixed I didn't know there WAS such a type as multipart/alternative, but I can certainly see the logic and use of such a thing.
OK. If it's mixed and not alternative, then why are we displaying the HTML in preference to the text/plain (and not offering the option to see the text/plain) in the first place? I bet this is the workaround for that outlook thing... :(
Status: UNCONFIRMED → NEW
Ever confirmed: true
can you attach the source of the message you have trouble with to this bug report. Feel free to sanitize it if needed (replace private information with xxx) Thanks
Created attachment 88963 [details] Sample of text/multipart where the two parts do not contain the same information Email showing 2 mime parts (text/multipart) Mozilla displays only one part, and shows no indication that the other part exists unless I go to view / Message Body As / ... or view the document source. This problem is caused by the groupwise internet agent (which converts internal groupwise mail messages into RFC822), but we should still handle this case. I think what happens is that the HTML and text encodings are done by the client when the appointment is created (they are identical at that stage), and the appointment information is only added to the text/plain version by the GWIA as it passes through it and converts it to an email, thus the text/plain section ends up different from the text/html one.
the sample message is a multipart/alternative with a text/plain and a text.html part. Mozilla correctly show the html part. The fact this message use apparently the wrong content-type (should be multipart/mixed) is not a Mozilla problem. It's not up to Mozilla to correct bad behavior created by others, it won't help making the internet world standard compliant. Invalid
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
Hmm you're right.. Sorry - I guess I must have pasted the Content-type line from the wrong message earlier on. Now... to bug Novell about getting groupwise fixed :)
Attachment #88963 - Attachment mime type: application/octet-stream → text/plain
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.