Bug 233542 - Evolution will not display the HTML part of a multipart message.
Evolution will not display the HTML part of a multipart message.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: evolution (Show other bugs)
5.0
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Matthew Barnes
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-03-22 21:07 EDT by John Bunch
Modified: 2007-11-30 17:07 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-28 22:31:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Multipart e-mail containing both text/html and text/plain parts. (63.17 KB, application/octet-stream)
2007-03-22 21:07 EDT, John Bunch
no flags Details
Multipart e-mail with text/html and text/plain parts swapped (63.06 KB, application/octet-stream)
2007-06-28 11:14 EDT, Matthew Barnes
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNOME Desktop 451976 None None None Never

  None (edit)
Description John Bunch 2007-03-22 21:07:40 EDT
Description of problem:
When reading a multipart e-mail containing both text/html and text/plain parts,
the text/plain part is always displayed.  Despite searching the preference
screens and the documentation, I was unable to find any way to display the
text/html part of the e-mail.

Version-Release number of selected component (if applicable):
2.8.0-33

How reproducible:
Always.

Steps to Reproduce:
1.  Read the attached multipart e-mail message in Evolution.
  
Actual results:
Only the text/plain part is displayed.

Expected results:
The text/html part should be displayed, as in Outlook.

Additional info:
Comment 1 John Bunch 2007-03-22 21:07:40 EDT
Created attachment 150711 [details]
Multipart e-mail containing both text/html and text/plain parts.
Comment 2 Matthew Barnes 2007-03-22 21:25:52 EDT
Look in

   Evolution Preferences -> Mail Preferences -> HTML Mail (tab)

What do you have selected in the "Plain Text Mode" section?

   Show HTML if present
   Prefer PLAIN
   Only ever show PLAIN

Does selecting "Show HTML if present" help?
Comment 3 John Bunch 2007-03-23 18:06:50 EDT
I believe something has been discovered.  There is no "Plain Text Mode" section
on the "HTML Mail" tab.  There are only two sections there:
1.  General
2.  Loading Images
Comment 4 Matthew Barnes 2007-03-23 18:21:23 EDT
Try enabling the "Prefer plain-text" plugin under Edit -> Plugins.
Comment 5 John Bunch 2007-03-23 18:52:03 EDT
All plugins are enabled, and there is no "Prefer plain-text" plugin in the list.
Comment 6 Matthew Barnes 2007-03-24 00:15:45 EDT
Huh, that's strange.  I see the plugin on Fedora Core, but not on RHEL 5.

This is not a new plugin, and they all should've been built into the package. 
Perhaps there are other missing plugins as well.

I'll investigate this further...
Comment 7 Matthew Barnes 2007-03-24 00:30:44 EDT
It seems this particular plugin was reclassified from 'experimental' to
'standard' during the 2.9 development cycle.  This happened in November of last
year, after RHEL 5 was feature frozen.  We don't build the 'experimental'
plugins into RHEL because they're considered unstable.

The bad news is I know of no other way to get Evolution to do what you want. 
The good news is no changes to the plugin were made between the RHEL 5 feature
freeze and when it got reclassified as 'standard', so if it's stable today then
it's also stable in RHEL 5.  So perhaps I can get this enabled for 5.1.
Comment 8 RHEL Product and Program Management 2007-03-24 00:43:17 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 10 Matthew Barnes 2007-06-28 11:14:56 EDT
Created attachment 158131 [details]
Multipart e-mail with text/html and text/plain parts swapped

There seems to be more to this bug than just the absence of that plugin, though
I'm still going to get the plugin included in RHEL 5.1.  I have several other
multipart messages containing both plain text and HTML for which Evolution
displays the HTML part by default.  So I took a closer look at these messages
and compared them with the above message (attachment #150711 [details]) and found a
couple differences in the structure of the message:

  1) In the messages for which the HTML part is displayed, the text/plain
     part comes first.	In the attachment above, the text/html part comes
     first.

  2) The attachment above contains extraneous MIME boundaries.

Here is a revised version of the message wherein I swapped the text/html and
text/plain parts and also removed the extraneous MIME boundaries.  If you
import this into Evolution you should find that the HTML part is displayed.
Comment 11 Matthew Barnes 2007-06-28 11:32:38 EDT
The latest upstream release (Evolution 2.11.3) also exhibits the behavior I
described in comment #10.  Therefore I'll have to fix this issue upstream first
and then hopefully I can just backport the patch to RHEL5.
Comment 12 Matthew Barnes 2007-06-28 14:42:31 EDT
I've opened an upstream bug [1] to track this issue.

[1] http://bugzilla.gnome.org/show_bug.cgi?id=451976
Comment 13 Matthew Barnes 2007-06-28 22:26:33 EDT
Having investigated this further, it has become apparent that fixing this
properly will require too intrusive of a change to Evolution for RHEL. 
Therefore I'm not going to fix this bug in RHEL, but I *will* pursue this upstream.

Here are my findings:

  - In the strictest interpretation of the MIME standard (RFC 1521),
    Evolution is not at fault here.  The MUA that composed the message
    in comment #1 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 the upstream bug I filed.  It should try harder to honor
    the user's preference for viewing HTML or plain text even if the
    message is not entirely standard compliant.

    Unfortunately, making this happen will require redesigning the
    "Prefer plain-text" plugin as well as parts of the core mailer.
    And that's just not an option for including in a RHEL5 update.
Comment 14 RHEL Product and Program Management 2007-06-28 22:31:09 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

Note You need to log in before you can comment on or make changes to this bug.