GNOME Bugzilla – Bug 451976
Evolution does not display HTML messages unless the text/html part is last
Last modified: 2008-04-17 09:52:23 UTC
An Evolution user sent me a multipart plaintext/HTML message that Evolution just refuses to render as HTML, regardless of my "Show HTML if present" configuration setting. It turns out that this particular message places the text/html part first, followed by the text/plain part. Most other HTML messages I have that *do* render correctly have the text/html part last. According to RFC 1521, the order of the parts *is* significant: 7.2.3 The Multipart/alternative subtype ... 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. It turns out that if I swap the text/html and text/plain parts so that text/html comes last, Evolution correctly renders the message as HTML. So even though this message may not be standard-compliant in terms of the ordering of its MIME parts, Evolution's "Show HTML if present" feature should still do what it says. Steps to Reproduce: 1. Enable the "Prefer plain-text" plugin. 2. Edit -> Preferences -> Mail Preferences -> HTML Mail (tab) 3. Select "Show HTML if present" in the "Plain Text Mode" section. 4. Pick any HTML message from an account and save it to disk. 2. Using an editor, swap the text/plain and text/html MIME parts so that text/plain appears last. 3. Import the message back into Evolution. Actual Results: Evolution will not render the message as HTML, regardless of my "Show HTML if present" preference. Expected Results: An HTML part is present so Evolution should show it, regardless of the order of MIME parts in the message.
Created attachment 90822 [details] HTML message with text/html part last Obviously there was supposed to be a step 5 and 6 above... Anyway, here's an example. This message puts the text/html part last. Evolution renders it as HTML when I tell it to.
Created attachment 90823 [details] HTML message with text/html part first Following the procedure above, I swapped the MIME parts so that text/html comes first, followed by the text/plain part. I cannot get Evolution to display this message as HTML, despite my "Plain Text Mode" preference.
Here's an update on my investigation of the issue. - In the strictest interpretation of the MIME standard (RFC 1521), Evolution is not at fault here. The MUA that composed the original message I mentioned in comment #0 is not following the standard. Section 7.2.3 on the multipart/alternative subtype states: "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." (emphasis mine) - The standard does, however, allow for some flexibility: It may be the case that some user agents, if they can recognize more than one of the formats, will prefer to offer the user the choice of which format to view. This makes sense, for example, if mail includes both a nicely-formatted image version and an easily-edited text version. In my view, this is what the "Prefer plain-text" plugin is doing; offering the user the choice of which format to view. And this is the gist of bug: the plugin should try harder to honor the user's preference for viewing HTML or plain text even if the message is not entirely standard compliant. It looks like the "Prefer plain-text" plugin will have to be redesigned in order to resolve this issue. If I understand the code correctly, it looks like emf_multipart_alternative() in "mail/em-format.c" always picks the last MIME part, and then hands that part to the plugin to decide "deal or no deal" on whether to display it as HTML (assuming the content-type is text/html). Instead, the plugin should be the one to choose the MIME part to display based on the user's preference. If the plugin is disabled, the mail component should fall back to a default behavior of choosing the last MIME part, as it does now. This will require a bit more work than I had hoped, but I think it's worth pursuing.
Bumping version to a stable release.
Created attachment 109302 [details] [review] proposed evo patch for evolution; prefer-plain tries harder to find an HTML part in multipart/alternative.
Matt, can you review/approve it?
Tested and it works great. Please commit, Milan.
Committed to trunk. Committed revision 35374. Committed to gnome-2-22. Committed revision 35375.