153551 - No obvious (any?) way to view text/plain mime portion without viewing doc source

Status: VERIFIED INVALID

(MailNews Core :: MIME, defect)

Description

[Ian Batterbee]

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.

Comment 1

[Matthias Versen [:Matti]]

what about view\Message Body\Text Plain ?

Comment 2

[Ian Batterbee]

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 ?

Comment 3

[Boris Zbarsky [:bzbarsky]]

Are these multipart/alternative messages?  Or multipart/mixed?

Comment 4

[Ian Batterbee]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

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... :(

Comment 6

[Jean-Francois Ducarroz]

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

Comment 7

[Ian Batterbee]

Attachment: 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.

Comment 8

[Jean-Francois Ducarroz]

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

Comment 9

[Ian Batterbee]

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 :)

Comment 10

[esther]

verified