GNOME Bugzilla – Bug 779370
<span> tag not stripped from mail preview
Last modified: 2018-02-07 06:52:28 UTC
Created attachment 346911 [details] faulty email I am still seeing "<span …>" in conversation preview for an email on master, see the attached mail. Cf screenshot http://i.imgur.com/h6NuQrf.png
Created attachment 347049 [details] another odd preview Here is another email that preview is odd, it prints > var chemindefer =3D""; > var reg=3Dnew RegExp("[ ,]+", "g"); But I am not sure who is to blame here, but just in case I'm attaching the email.
Gautier, can you attach a screenshot of the odd preview? Don't have time to figure out how to configure sendmail to test sending the attached eml files...
Created attachment 365768 [details] screenshot of the issue Sure, here is a screenshot. Tell me if you need more!
Sure, I misread previous comments. There was already all the information needed. I have the feeling that the email is not correct, as the plain text part contains an HTML tag (<span>). Perhaps Geary is using the plain text part to display the preview in the conversation list and shows what it would be supposed to be plain text. This is the relevant part of your attached "faulty email" file: Content-Type: multipart/alternative; boundary="----=_Part_98675_1500566573.1487758316778" ------=_Part_98675_1500566573.1487758316778 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable <span style=3D"font-family:arial,helvetica,sans-serif; font-size:12px">=E2= =80=8CF=C3=A9bug!</span> ------=_Part_98675_1500566573.1487758316778 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <span style=3D"font-family:arial,helvetica,sans-serif; font-size:12px">=E2= =80=8CF=C3=A9bug!</span> I don't think that Geary should work around incorrect emails. If my understanding is correct..
Yeah maybe it makes sense not to fix it. The two alternatives I can think of are: 1) display text as HTML for preview too (eg use text/html before text/plain if available) - at least in that case it would solve the issue. 2) strip any (html) tags from text/plain before rendering it but you may end up with invalid stripping... maybe not a good solution. Maybe checking if text/plain text is equal to text/html could be enough, but I don't know how many ppl cannot send proper emails actually so maybe this is an isolated email (from a huge agency though).
Hmm, yeah I don't think we can do anything much about clients that send HTML in text/plain, but in any case if we were fetching the body part we'd know about the HTML part existed, and could use that for the preview instead. So this is basically a dupe of Bug 777118. *** This bug has been marked as a duplicate of bug 777118 ***