GNOME Bugzilla – Bug 470291
[prefer-plain] When using text-only display mode, HTML part is shown as attachment
Last modified: 2009-10-30 13:03:47 UTC
I got plaintext-only mode configured in Evolution. Whenever I get an email which contains both a text and a HTML message part, the text part is displayed like it should, but also one attachment of type "unknown attachment" is displayed in the same way as any "normal" attachment. This is pretty confusing as it is no attachment at all, and the attachment display bar eats up some space in the UI.
can you please attach a sample mail after removing confidential information and if possible try in current stable 2.22.2, thanks.
I can confirm this bug. HTML emails sent appear only as an attachment, with no message body. Expected result: HTML should be converted to text insofar as possible (perhaps like html2text). $ evolution --version GNOME evolution 2.22.3.1 Installed via debian "lenny". The message source is provided below X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from IP([IP]) by MAILSERVER ([IP1]) via Exchange Front-End Server www.SERVER.TLD ([IP2]) with Microsoft Exchange Server HTTP-DAV ; Thu, 12 Feb 2009 01:41:50 +0000 MIME-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable User-Agent: Microsoft-Entourage/11.3.6.070618 Content-class: urn:content-classes:message Subject: SUBJECT Date: Thu, 12 Feb 2009 TIMEZONE Message-ID: <USERID> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TOPIC thread-index: DATA From: FROMFIELD To: ADDRESS X-Evolution-Source: exchange://MYACCOUNT/ <HTML> <HEAD> <TITLE>EMAILTITLE</TITLE> </HEAD> <BODY> <FONT FACE=3D"Verdana, Helvetica, Arial"><SPAN = STYLE=3D'font-size:12.0px'>Dear colleagues<BR> <BR> This is a memo<BR> <BR> Many thanks<BR> <BR> Person<BR> -- <BR> SNIP SIGNATURE </SPAN></FONT> </BODY> </HTML>
(In reply to comment #2) > I can confirm this bug. HTML emails sent appear only as an attachment, with no > message body. > > Expected result: > HTML should be converted to text insofar as possible (perhaps like html2text). This is a (slightly) different issue. Comment #0 concerns the fact that the prefer-plain-text plugin will (in either prefer plain of plain only mode) transform the text/html part into an attachment. Reporter suggests to not do that (and entirely hide the text/html part). Your example mail is only text/html (i.e. it has no text/plain part). This means that in plain-only mode there's nothing left to show but an attachment.html (of type unknown attachment). The prefer-plain plugin is doing here just what you asked it. For converting html to text (in cases like your mail) you might consider opening a separate bug (but please check whether something like that hasn't been filed yet).
Done as Bug 575788
Nicolas, it had been done intentionally, to allow user show also the html part, in case it contains something important. I wonder whether we really want to hide it completely. Any idea, Matt?
First question is why Evolution does not recognize the text/html part. I ought to be able to view it inline, like any other text attachment. Once that's fixed, I think a reasonable behavior is to show the text/html part as an attachment (collapsed, but viewable) if "Prefer PLAIN" is selected but hide it if "Only ever show PLAIN" is selected. I use "Prefer PLAIN", but sometimes I do want to see the HTML version of certain emails. This approach would let me do so without having to go into Preferences and flip the master switch for all emails.
With "prefer plain" it is working as you said. But the "Only ever show PLAIN" isn't. Thus I will fix it.
Hrm, so the prefer-plain plugin influences two parts: a) multipart/alternative - based on its options it shows/hides html part from there, which is, in my opinion, the right thing b) text/html - it blocks these parts with "Only ever show PLAIN", no matter if it's part of the a) or a single part of the email, even requested by user to show this part. Note that hiding the HTML part completely makes a message from comment #2 empty, which is incorrect. Thinking of it, I believe the correct behaviour of prefer-plain would be: a) Never hide HTML parts for a user, the most collapse them as attachments b) When user requests to expand such HTML part then show it With the above, even with "Only ever show PLAIN" will offer a possibility to show the part, which would be otherwise hidden.
Created attachment 140011 [details] [review] proposed evo patch for evolution; This makes it for me. Please test someone. If accepted, the bug 575788 can be marked as a duplicate. (It's easier to solve this in one bug than in two.)
*** Bug 546664 has been marked as a duplicate of this bug. ***
>With the above, even with "Only ever show PLAIN" will offer a possibility to >show the part, which would be otherwise hidden. If html is not going to be converted to plain text, could you please rename this option "Prefer plain text"? As it stands, it makes it seem like there will be a conversion. I think it would be good to change it to something like "Present html message components as attachments" or "Plain text when available" or whatnot. Is it, from a technical viewpoint, not feasible to open a pipe, and use html2text to perform the conversion (which preserves tables quite well)? I realise this adds a dep on an external python program... In case anyone is still reading :) I, in my brief several minutes of reading, do note that some glib programmers have done similar things with SSH streams and glib IO channels [1] Thanks for taking the time to look at this bug
Converting the combo box in Preferences to radio buttons and using more verbose descriptions for each choice would not be a bad idea.
Created commit be17ff0 in evo master (2.29.1+) Slightly modified patch, with added info label, with a little description. I didn't want to convert combo to radio, even there seems to be enough space, but who knows, maybe after some time, the space will have its occupant. Feel free to suggest better texts.
*** Bug 570931 has been marked as a duplicate of this bug. ***
After re-reading bug #570931, I thought of a possibly clearer wording for the options: Show HTML if present Show plain text if present Only ever show plain text
Maybe change the last one to "Do not show HTML inline " ?
I changed the wording as requested in comment #15 within bug #583450. Note the options have a little description label under the dropdown combo, thus it should be slightly more clear what it means.