130119 - Option to choose what part of multipart/alternative message to display

Status: VERIFIED DUPLICATE of bug 602718

(MailNews Core :: MIME, enhancement)

Description

[Jean-Marc Desperrier]

When a multipart/alternative message is received, Mozilla will determine what
part of the message it wants to display and there's no way for the user to get
Mozilla to display another part.

There should something in the GUI to enable to change the display to another of
the multipart/alternative forms available in the message. 
This could also be a static preference with an ordered list of prefered format.

There are many opened bugs about how to get rid of the problems with HTML in
mail (for exemple bug 108153), but they all go about how to convert the HTML
back to plain text or to innocent HTML. This will not really solve this problem
as it will not help for messages with only HTML content, but it's simpler to
implement and I feel they are perfectly valid reasons for wanting to see what
the message looks in another format than the one selected by Mozilla.

This would also help for bugs like bug 130118, where Mozilla select the wrong
format.

Comment 1

[phil]

this probably depends on bug 127612
There is also bug 142092 but I don't know if the second comment means that a
solution would be available.

When a multipart/alternative message is received, Mozilla uses the last part.
RFC 1521  (http://www.faqs.org/rfcs/rfc1521.html) says it should be the case
(7.2.3.)
"
   In general, user agents that compose multipart/alternative entities
   must place the body parts in increasing order of preference, that is,
   with the preferred format last.  For fancy text, the sending user
   agent should put the plainest format first and the richest format
   last.  Receiving user agents should pick and display the last format
   they are capable of displaying.  In the case where one of the
   alternatives is itself of type "multipart" and contains unrecognized
   sub-parts, the user agent may choose either to show that alternative,
   an earlier alternative, or both.
"

The choice Edit/Preferences/Languages/Languages for web pages could probably be
used to fill that suggestion (the content of the header X-accept-Language:)

Comment 2

[phil]

RFC 2046 made the 1521 obsolete (http://www.faqs.org/rfcs/rfc2046.html)
but the chapter is the same (5.1.4.)
Just before there is this paragraph:
"
   Systems should recognize that the content of the various parts are
   interchangeable.  Systems should choose the "best" type based on the
   local environment and references, in some cases even through user
   interaction.  As with "multipart/mixed", the order of body parts is
   significant.  In this case, the alternatives appear in an order of
   increasing faithfulness to the original content.  In general, the
   best choice is the LAST part of a type supported by the recipient
   system's local environment.
"

Comment 3

[John Malmberg]

Mozilla should provide a visible indication of what alternative formats are
available for the message, and if the user wants to temporarily change their
display preference to see the different format, they should be able to do so.

Comment 4

[Brett Johnson]

Attachment: multipart/alternative with ical attachment

I've attached an example which illustrates the problem with hiding the
attachments from the user.

The attached email is a meeting request from a mSexChange server, which
contains 3 alternatives (text/plain, text/html, and text/calendar).  Mozilla
does the correct thing in displaying the html alternative, since it doesn't
have the ability to display text/calendar.  However, since mozilla gives no
indication that there are additional alternatives, there is no way to extract
the (very useful BTW) ical attachment in this message (for import into the
calendar extension, for example).

IMO, the ideal behavior in this case would be for mozilla to continue to
display the html, but show the attachment bar for the text/calendar attachment
(i.e., continue to use the same algorithm for determining which of the
alternatives to display, but then if there are additional alternatives, show
them as open/save-able attachments to the message, as if they were
multipart/mixed or something).

This is related to resolved bug 130118, but the problem statement and fix in
that case did not consider what should really be done with the un-displayable
text/calendar attachment.

Comment 5

[Andre-John Mas]

This issue affects bug 59630, amongst others. We really do need some way of
displaying the alternatives. Maybe from the pop-up menu or/and from the menu
'View -> Message Body As'?

Comment 6

[Bernd Eilers]

I second the request to be able to select the alternatives. I think this is also especially needed to support assistive accesiblity tools better. E.g. if some text has been send as text/plain and text/html the tools a blind user uses may be easier to use with the text/plain part than using the text/html part. 

If an email has been send as multipart/alternative with text/plain and text/html the sender most likely provided a better text/plain formatting than an automatic conversion of the text/html part can provide. But when using the menu entry "View / MessageBody As / Plain Text" the automatic conversion is currently being used although there IS a text/plain alternative available, i think this is simply a bug.

Additional note: StarOffice 5.2 had some means to select between alternative formats of a mail in multipart/alternative messages using a treeview, maybe it´s worth a look on how it was done there.

Comment 8

[Andrew Brown]

Could this be done in a add-on rather than core??

OR if in core add Force HTML to the View->Message Body As-> menu choices.

View -> Message Body As -> Original HTML
                        -> Simple HTML
                        -> Force HTML 
                        -> Plain Text

I have been looking for a solution to this problem because a user of Adobe ColdFusion MX sends me malformed multipart/alternative newsletters.  I only ever see the badly formatted plain text version the author creates.
Thunderbird formats correctly (to RFC). The problem is at the authors end, but they won't fix it. The just have the text/html ahead of text/plain instead of the other way round.

Sample below:

Mime-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_11547_2367522.1195021713066"
X-Mailer: ColdFusion MX Application Server

------=_Part_11547_2367522.1195021713066
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

[snip]
full html version
[snip]

------=_Part_11547_2367522.1195021713066
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

[snip]
badly formatted plain text content
[snip]

------=_Part_11547_2367522.1195021713066--

Comment 9

[Wayne Mery (:wsmwk)]

protz, is this still reasonable and needed?

Comment 10

[Jonathan Protzenko [:protz]]

People, could you check whether the new display option "View All Body Parts" fixes your problem? I think yes. Long story short,
- set the hidden pref mailnews.display.show_all_body_parts_menu to true,
- hit View > Message Body As > All Body Parts.

Thanks,

jonathan

Comment 11

[Andrew Brown]

(In reply to Jonathan Protzenko [:protz] from comment #10)
> People, could you check whether the new display option "View All Body Parts"
> fixes your problem? I think yes. Long story short,
> - set the hidden pref mailnews.display.show_all_body_parts_menu to true,
> - hit View > Message Body As > All Body Parts.

I3 years later, I no longer use Thunderbird day to day, but have saved emails that had this problem.  I am willing to check if I can get the right version installed on Windows 7 for testing.

I updated to the latest release, but the hidden pref is not in TB 6.01. I presume it is in the beta to 7.0 or current nightly, but can't find a link to them. 

Please confirm which version you want testing against and a DL link for the Windows version.

Comment 12

[Andrew Brown]

(In reply to Jonathan Protzenko [:protz] from comment #10)
> People, could you check whether the new display option "View All Body Parts"
> fixes your problem? I think yes. Long story short,
> - set the hidden pref mailnews.display.show_all_body_parts_menu to true,
> - hit View > Message Body As > All Body Parts.

Confirm this solves my problem
 - tested on Earlybird 8.0a2(2011-08-31) on Windows 7

Comment 13

[Jonathan Protzenko [:protz]]

Thanks you very much for taking the time to try the new version!