GNOME Bugzilla – Bug 620716
Evolution fails to display HTML mail from IMAP accounts
Last modified: 2011-09-29 09:30:19 UTC
As the title says, HTML mail fetched via POP3 will render ok, the same message fetched via IMAP will not. Please see Ubuntu bug for various details and all the users who reported this: https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/323335
Please attach an example message here and a CAMEL_DEBUG log. See http://projects.gnome.org/evolution/bugs.shtml
Created attachment 162904 [details] Example HTML message that does not display correctly in IMAP account
Created attachment 162906 [details] Log of starting Evolution and saving example message
I can confirm the problem. This happens also when using libmapi for interconnection with MS-Exchange. As far I understood it is only an issue under 64-bit. But could it be a problem with libgtkhtml ?
Maybe, to be a bit more clearer what the problem exactly is, I will cite User "Dejan" from bugs.launchpad: ________________________________________________________________________________ I confirm this problem on Ubuntu Lucid 10.04 RC with latest updates on x86_64 with Evolution MAPI using Exchange 2007. I am using croatian keyboard hr_HR.UTF8 What I see is this: ------------------------- Dobar dan. [?] [?] ------------------------- Mail source (without e-mails from/to) is: ----------------------------------------- MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.3 September 26, 2007 Message-ID: <OF4A2E995B.D0C136A4-ONC125770E.004F9229-C125770E.004FBC8F@xxxxxx.hr> Date: Fri, 23 Apr 2010 16:30:56 +0200 X-MIMETrack: Serialize by Router on XXXXX1/XXXX(Release 7.0.1|January 17, 2006) at 23.04.2010 16:30:56, Serialize complete at 23.04.2010 16:30:56 Return-Path: something@xxx.hr Subject: Kvote za Q1 Content-Transfer-Encoding: 8bit Content-Type: text/html; charset="CP28592" <br><font size=2 face="sans-serif">Dobar dan.</font> <br><font size=2 face="sans-serif">molim vas da to prije izraunate i dostavite ostvarenje kvota za Q1 po target leterima, i Goran vam ih treba ovjeriti</font> <br> <br> <br><font size=2 face="sans-serif">S potovanjem<br> <br>
I can confirm that this occurs to me on Ubuntu 10.04 amd64, using evolution-mapi 0.28.3-0ubuntu1, libexchangemapi1.0-0 0.28.3-0ubuntu1, and libmapi0 1:0.8.2+svn1524-1. However, it does not happen to me using IMAP, rather it happens quasi-randomly using Exchange-MAPI against an Exchange 2008 server. I say "quasi-randomly" because I had one message I could not view correctly, every time, until I started typing this comment then suddenly it rendered the HTML properly. Just like taking my car to the repair shop! What I *was* seeing consistently was that when another user (same setup as me) sent an HTML-formatted message from Evolution through exchange-mapi connection, I would see the HTML source instead of the formatted display. I did not try selecting another character encoding, I only learned about that possible workaround today - but it's suddenly working.
Aha! I found an email where it still happens. Selecting an alternate character encoding DOES change the display: UTF-8 looks the same as "Default", I see the HTML source: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.28.3"> </HEAD> <BODY> 1> PDF doc- HTML tag is not render in pdf publishing, for example if the field has html tag ,it doesn’t render properly on the pdf.<BR> <BR> <FONT COLOR="#0000ff">I like your [...] If I choose "Western European", I see the UTF-8 prelude bytes (looks kinda like yP, but obviously both Unicode characters). If I choose UTF-7 the message suddenly displays correctly (the HTML is processed and formatted correctly). I suspect the original Ubuntu bug is actually at least two different bugs... Attempted to follow the instructions at http://projects.gnome.org/evolution/bugs.shtml, but none of my log files appear to contain the offending message! Attaching them anyway...
Created attachment 169900 [details] Run from "CAMEL_DEBUG=all CAMEL_VERBOSE_DEBUG=1 E2K_DEBUG=5 evolution >&evo.log"
Created attachment 169901 [details] Log from "E2K_DEBUG=5 /usr/lib/evolution/2.28/evolution-exchange-storage >& ees.out.2" Looks useless, but including for completeness.
Created attachment 169902 [details] same as previous run, but this time after starting exchange-storage separately
Is this still an issue in Evolution 3.0.3 or Evolution 3.2 ?
Don't know - unable to test this until I migrate our Exchange server back in-house (current outsourced host [BPOS] does not allow MAPI or IMAP). I would say most likely, yes, since the bug actually appears to be a 64-bit issue in a gtkhtml component that Evolution merely triggers. (Yes, that could possibly be a 64-bit bug in Evolution that exercises GIGO in gtkhtml, it's not 100% clear which.) I haven't see any reports of this behaviour from anyone running 32-bit, except for one reporter on Launchpad who claimed to be somehow running 32-bit userland on 64-bit Ubuntu. Not sure if I really believe that particular report... I haven't looked at the changelog for GTK, it's possible they've fixed something in the meantime...
I had a HTML e-mail in a POP account that I did a "drag and drop" into my IMAP Inbox, it looked ok. I then did a Forward As-Redirect on it and the new message window appeared all munged, so whatever mechanism that invokes seems to have the same issue as genuinely received HTML e-mail to IMAP accounts. I use 64-bit Ubuntu 10.04 (Evolution 2.28.3).
Closing as OBSOLETE - 2.28 is more two years old and not supported anymore. GNOME developers are no longer working on that version, so unfortunately there will not be any bug fixes for the version that you use. By upgrading to a newer version of GNOME you could receive bug fixes and new functionality. You may need to upgrade your Linux distribution to obtain a newer version of GNOME. Please feel free to reopen this bug if the problem still occurs with a newer version of GNOME (3.0 or 3.2).
I made an error in my previous post, when I did the "Redirect" the edit screen was in text mode, changing to HTML rendered the message correctly and then the message was sent to the IMAP account successfully - it now renders ok.
Sorry, fixing status.