Closed Bug 394322 Opened 17 years ago Closed 6 years ago

forward inline from Simple HTML view creates blank email if html tag has attribution (typically originating from MS software)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(thunderbird_esr52 fixed, thunderbird_esr60 fixed, thunderbird60 fixed, thunderbird61 wontfix, thunderbird62 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 62.0
Tracking Flags:
Tracking Status
thunderbird_esr52 --- fixed
thunderbird_esr60 --- fixed
thunderbird60 --- fixed
thunderbird61 --- wontfix
thunderbird62 --- fixed

People

(Reporter: bugzilla, Assigned: jorgk-bmo)

References

Details

Attachments

(3 files, 11 obsolete files)

multipart-related.eml
(deleted), text/plain
Details
394322-tests.patch (v2)
(deleted), patch
aceman
: review+
Details | Diff | Splinter Review
394322-html-tag.patch (v4c)
(deleted), patch
jorgk-bmo
: review+
jorgk-bmo
: approval-comm-beta+
jorgk-bmo
: approval-comm-esr60+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Build Identifier: version 2.0.0.6 (20070728) When viewing an HTML message as simple HTML, if I click on forward (inline is my default) Thunderbird creates a message with the proper header information and my signature. The body of the message I wanted to forward is omitted. I have tried the other cases and this seems to be the only way I could get a blank message from forwarding. If I viewed as original html or plain text it worked inline and it works when forwarding as an attachment as well. Reproducible: Always Steps to Reproduce: 1. View message body as simple html 2. Choose message forward as inline 3. Observe misssing message body in the compose window Actual Results: headers but no body Expected Results: headers and body quoted in the compose window This is a slighly anonymized sample of a whole folder of messages I have that will produce these results. Return-Path: <operations@intelesure.com> From: <operations@intelesure.com> To: <redacted@example.com> Subject: SmartReceptionist Message Date: Sat, 7 Apr 2007 09:25:50 -0600 MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_05B2_01C778F6.BDC65C50" X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 This is a multi-part message in MIME format. ------=_NextPart_000_05B2_01C778F6.BDC65C50 Content-Type: multipart/alternative; boundary="----=_NextPart_001_05B3_01C778F6.BDC65C50" ------=_NextPart_001_05B3_01C778F6.BDC65C50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARSHA PLEASE CALL Toll Free (866) 808-7366 Fax (877) 873-9633 E-mail: operations@intelesure.com ------=_NextPart_001_05B3_01C778F6.BDC65C50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = xmlns=3D"http://www.w3.org/TR/REC-html40"> <head> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; = charset=3Dus-ascii"> <meta name=3DGenerator content=3D"Microsoft Word 11 (filtered medium)"> <!--[if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--> <title> </title> <style> <!-- /* Font Definitions */ @font-face {font-family:Verdana; panose-1:2 11 6 4 3 5 4 4 2 4;} /* Style Definitions */ p.MsoNormal, li.MsoNormal, div.MsoNormal {margin:0in; margin-bottom:.0001pt; font-size:12.0pt; font-family:"Times New Roman";} a:link, span.MsoHyperlink {color:blue; text-decoration:underline;} a:visited, span.MsoHyperlinkFollowed {color:blue; text-decoration:underline;} p {mso-margin-top-alt:auto; margin-right:0in; mso-margin-bottom-alt:auto; margin-left:0in; font-size:12.0pt; font-family:"Times New Roman";} span.EmailStyle18 {mso-style-type:personal-compose; font-family:Verdana;} span.comment1 {font-family:"Times New Roman"; color:black; font-weight:normal; font-style:normal; text-decoration:none none;} span.question1 {font-family:"Times New Roman"; color:black; font-weight:normal; font-style:normal; text-decoration:none none;} span.response1 {font-family:"Times New Roman"; color:black; font-weight:normal; font-style:normal; text-decoration:none none;} @page Section1 {size:8.5in 11.0in; margin:1.0in 1.25in 1.0in 1.25in;} div.Section1 {page:Section1;} --> </style> <!--[if gte mso 9]><xml> <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" /> </xml><![endif]--><!--[if gte mso 9]><xml> <o:shapelayout v:ext=3D"edit"> <o:idmap v:ext=3D"edit" data=3D"1" /> </o:shapelayout></xml><![endif]--> </head> <body lang=3DEN-US link=3Dblue vlink=3Dblue> <div class=3DSection1> <p class=3DMsoNormal><b><font size=3D3 face=3D"Times New Roman"><span style=3D'font-size:12.0pt;font-weight:bold'>MARSHA PLEASE = CALL<o:p></o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack = face=3DVerdana><span style=3D'font-size:11.0pt;font-family:Verdana;color:black;font-weight:bol= d'><img width=3D221 height=3D40 id=3D"_x0000_i1025" = src=3D"cid:image001.gif@01C772E3.3C640900"><o:p></o:p></span></font></b><= /p> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack = face=3DVerdana><span style=3D'font-size:11.0pt;font-family:Verdana;color:black;font-weight:bol= d'>Toll Free (866) 808-7366<o:p></o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D2 color=3Dblack = face=3DVerdana><span style=3D'font-size:11.0pt;font-family:Verdana;color:black;font-weight:bol= d'>Fax (877) 873-9633 </span></font></b><b><font size=3D2 color=3D"#333366" = face=3DVerdana><span style=3D'font-size:11.0pt;font-family:Verdana;color:#333366;font-weight:b= old'><o:p></o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D3 color=3Dblack = face=3DVerdana><span style=3D'font-size:12.0pt;font-family:Verdana;color:black;font-weight:bol= d'>E-mail: <a = href=3D"mailto:operations@intelesure.com">operations@intelesure.com</a></= span></font><font color=3Dblack><span = style=3D'color:black'><o:p></o:p></span></font></b></p> <p class=3DMsoNormal><b><font size=3D3 color=3Dblack = face=3DVerdana><span style=3D'font-size:12.0pt;font-family:Verdana;color:black;font-weight:bol= d'><o:p>&nbsp;</o:p></span></font></b></p> </div> </body> </html> ------=_NextPart_001_05B3_01C778F6.BDC65C50-- ------=_NextPart_000_05B2_01C778F6.BDC65C50 Content-Type: image/gif; name="image001.gif" Content-Transfer-Encoding: base64 Content-ID: <image001.gif@01C772E3.3C640900> R0lGODlh3QAoAHcAMSH+GlNvZnR3YXJlOiBNaWNyb3NvZnQgT2ZmaWNlACH5BAEAAAAALAAAAADc ACcAhwAAAAAAAAAAMwAAZgAAmQAAzAAA/wAzAAAzMwAzZgAzmQAzzAAz/wBmAABmMwBmZgBmmQBm zABm/wCZAACZMwCZZgCZmQCZzACZ/wDMAADMMwDMZgDMmQDMzADM/wD/AAD/MwD/ZgD/mQD/zAD/ /zMAADMAMzMAZjMAmTMAzDMA/zMzADMzMzMzZjMzmTMzzDMz/zNmADNmMzNmZjNmmTNmzDNm/zOZ ADOZMzOZZjOZmTOZzDOZ/zPMADPMMzPMZjPMmTPMzDPM/zP/ADP/MzP/ZjP/mTP/zDP//2YAAGYA M2YAZmYAmWYAzGYA/2YzAGYzM2YzZmYzmWYzzGYz/2ZmAGZmM2ZmZmZmmWZmzGZm/2aZAGaZM2aZ ZmaZmWaZzGaZ/2bMAGbMM2bMZmbMmWbMzGbM/2b/AGb/M2b/Zmb/mWb/zGb//5kAAJkAM5kAZpkA mZkAzJkA/5kzAJkzM5kzZpkzmZkzzJkz/5lmAJlmM5lmZplmmZlmzJlm/5mZAJmZM5mZZpmZmZmZ zJmZ/5nMAJnMM5nMZpnMmZnMzJnM/5n/AJn/M5n/Zpn/mZn/zJn//8wAAMwAM8wAZswAmcwAzMwA /8wzAMwzM8wzZswzmcwzzMwz/8xmAMxmM8xmZsxmmcxmzMxm/8yZAMyZM8yZZsyZmcyZzMyZ/8zM AMzMM8zMZszMmczMzMzM/8z/AMz/M8z/Zsz/mcz/zMz///8AAP8AM/8AZv8Amf8AzP8A//8zAP8z M/8zZv8zmf8zzP8z//9mAP9mM/9mZv9mmf9mzP9m//+ZAP+ZM/+ZZv+Zmf+ZzP+Z///MAP/MM//M Zv/Mmf/MzP/M////AP//M///Zv//mf//zP///wECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwEC AwECAwECAwECAwECAwECAwECAwECAwECAwECAwECAwj/ALEJHEiwoEGD0aC1OsiwocOHECNKnEix osWLGDM2hEYqmsaPIEOKHEkS40KDJwumHHitkzOPBFcOlCmQJjabOA/mRKmzJ8+fKn0GBRpTaFGi M42WFHht1DFoS6NKnUq1qsZno5CRssq1q9evIqFpPfYMrNmzaCnuHMoWG1ZnWaEebZsUaU2ld+3e xLtX79q5gOvSzTu4b2GbIKFlRaa1bNrHkB8n+nLF2aqMrODCRTbK2dbIoENb/VKjxg5Sx7KSegbt 2rWG0a5Be8Z4MWfGjkXr3h0y0Q4aX2js0KM5a+fOpIpvNq78ODKPfwUHJjzdcPXo1KVrz87d+nbv 3bGD//deOngNGudRa2W8nlT79+7dI1NlyJBc3vjzVwTOP/iXCF4kx9yAnC23nCqAGIKYfgw2KJBv 6EVYHno1tAKNM7XdZptt9dUnUyv+ffHFIK7o9syJJ0Jzn37XnEhSKc+8ZlEiwJ2kSH/8DRQbK9Cs 8gyMq/QIjSEIGsKKYRH+dt4OECQSHl/itVIDBCqlhkwnt3Wy4pN+QTlTatjQMhArYIrZ5U/HdCJj TtekORNpBiUZIUTXdGhkQaTRkIiYrrhC2hdnoWeQU60lVJuMkTmFKDYt5hbSiYs2lBWikx2E4w6D OHTNH6skaIhK55VYUCKKMPQhLTihSlFwBV3DWUGdlf9yECvXwDRrpDpesyCjRxYE10S0alqrRNf0 StCrAw1iZpwT0uBQh/RZSsOyDEFQQyLnnQcojTTMORCN53VbA6ADBZcIiOiZF5y4Ah1zzKLPkEVQ NJyldgwyBYnllFPIIIqVu6n5G6u9ozgWzWL7HsOoUwRBQ7C8A2F1IsGOdjKKvw9vFY2V+yJzLlsQ +KenQSUS+YcqfzD0G7mALRmycDCvLJwX5Z43WXA70CzQF78xqS2OrLby6rJZXbYQvZ3xaNxA+lr2 L1RCx8rRlQOtouFbo8hl3DPJbRU10wX6qNpepVxtHKLIYuNewTA61co1AnrmmZMN0SjzQavUp0oh sjD/lCdwg+zJLMvYAvetoANR6wri2AySLrWMD8RwxJyhXTBBhLZ7ecRQYYXvQIwlI5BiyNxXm+QK E9TU59hwlltTTwnk+X3yof5amxcTFKNAWRVWbn86j4kggpc1xLOc4xL0W0GGzzSlTrQMsvzOO7Bc E6vzur6acdaw1HvDl1vz/aAvqd6ZQFZ/JvlzAv2a/ShMjS/75mUXL5D4zgwEJu/OGPt+RdkyTUH0 Vh9ckWwQpAkXy9CzLFp0i3nOqlm3IhTBxo2MeTUYVL3ulTuwJcwp99oKbdQ3r3vVq2OpU4yjsBGw dvVLdfcanVbyNUO3bE6G6lOUQK7WGsyl7jCNk5mo/7CxipMR6VN6+V0NxHSN8zBvB8tyBZMGAjMR uWIyVNpZ8mIyvZlU7m3IAZ9nuEZGUnTuhoZBThnJiL4arg9qQ/Mi/LChwladj4jIkJX3cpO2Vnhu a0zso0RgtsVrFII+hiiEAR9Ci/OYKXLYcCJBECclGgwRG4xzXKYwOKgfki43DmOdQeIlSpbsjyF1 PFYHdei9zzmMhG45xmck1rAY8u5dBUnI2rT2QoosDmcLAcTwAGE/ndCtIA7cwUm6KJAaOS+CvyRI IyvIM+thw08VZEra6JgVPWIjLgxZXaQ8EquGpM98n7uG+3SErNXZyoaOKZs3F5Y/zTUkPthA2kX+ pP+nOtlpV7Sw1jGv2a0FLjFxkqRiBLklKmxW0HEDbea1CuIueLlLLrexlTodcxuWlC6WH2UKbUZH FhnBjo/IcNTqQDe+eB0DJrQEWw5xubEVue6WWzqMtr4QC5NFKzCVlBnOspnQZkJxL654nlH5o60s YuNP1hlq0OI4ELgc40hIc51x5KIvrVgVKrT4I9euVE+rGUdDulPNr1pxyqwKCBlGw4Y8zVdPFnaC KVhCTkbn59U5SgQL2UoFAf3HkCtmIVvAiWjzalaQLWpROF+gRfUOF9GdRYhc7sEVeyK2tsYgqkUd c5RYbpNSmJAuQyu0YUfhJkrQWmlFHIEtY0DXy6n/qWaF/0IjRH5Zg2GqYlcOmsoiWVKQc4pkuEtB bkOydcT6BDe4qXxuQ6IjIhoc4pCc4lJNFsJdwQiiFYJISkq424rykje82z1Jea0D3vUS5rvjBe9A 4NsT885EvgL5LnoHUgpZAvFM/w1wdRzSCvR4yhDFfIgg9rvg/ArkCnlZb4PR+92YLITBJ2kwNihM XoOgV70rkW+F8btfCD+4wxU2SGylC5JW7KAGRURZ3yISXgZv+MYbTrGDJ5zf9vZ4wyDuMX1xzBAN 10S/8wXyg2+Skg9/CMksjgpgVYFIVczKIFcAL4WZvN+bYBjIGVbJguO7Y/ma2cgWdnJMFrxf8zb5 mcgF0XGUL7ITRcyAPihTRYINESkSOzjHTF5yftFr4ht3l8NwxnGWTyzo+y7ExGZOsns3XGj8Klm9 4e0ugK/jpU1/ZyKKsJOdVpE3JLJFvXUpb5f7Mt4hs/rHhmk1TiztZlTH2sKy3q6c5zySVfhWmCdL MK+HTWwiivpOxU72bsRToretQlfT7bSAvxMlaXPa09q99rSzPZOAAAA7 ------=_NextPart_000_05B2_01C778F6.BDC65C50--
i've the same problem with thunderbird 1.5 and 2 also on windows XP: From - Tue Oct 30 14:59:11 2007 X-Account-Key: account2 X-UIDL: 46cbd5c300000050 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00000000 Return-Path: <marco...@cos....it> Received: from Direzione (host120-177-static.25-87-b.business.telecomitalia.it [87.25.177.120]) (authenticated bits=0) by mail.tesene.it (8.13.1/8.13.1) with ESMTP id l9TCUuo1010932; Mon, 29 Oct 2007 13:30:57 +0100 Message-ID: <025501c81a27$84e86a90$5601a8c0@Direzione> From: "marco..." <marco...@cos....it> To: "massimo" <massimo...@cos....it>, Subject: orario segreteria Date: Mon, 29 Oct 2007 13:30:40 +0100 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0252_01C81A2F.E648B990" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.3138 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198 X-Tesene-MailScanner-Information: Per ulteriori informazioni http://www.tesene.it/mailscanner X-Tesene-MailScanner: Nessun virus rilevato X-Tesene-MailScanner-SpamCheck: non spam, SpamAssassin (not cached, punteggio=-1.439, necessario 6, autolearn=disabled, ALL_TRUSTED -1.44, HTML_MESSAGE 0.00) X-Tesene-MailScanner-From: mmarco...@cos....it X-Tesene-Spam-Status: No Status: X-Antivirus: AVG for E-mail 7.5.503 [269.15.12/1098] This is a multi-part message in MIME format. ------=_NextPart_000_0252_01C81A2F.E648B990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Come gia cominicatoti verbalmente di preciso [...]
The example you post here should trigger bug 307023 (quoted-printable HTML): > Content-Type: text/html; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable In that case, you would see the text but not the images. Those should show up as blank box with broken-image icon when viewed as Original HTML and then opened for HTML composition when forwarding. Did you test this with somewhat more complex examples?
(In reply to comment #2) > The example you post here should trigger bug 307023 (quoted-printable HTML): I agree that on first glance this should trigger bug 307023, but after reading through the comments on that bug I believe that this is a different issue. The message I quoted above doesn't match up with the comment #15 on that bug. https://bugzilla.mozilla.org/show_bug.cgi?id=307023#c15 > In that case, you would see the text but not the images. Those should show up > as blank box with broken-image icon when viewed as Original HTML and then > opened for HTML composition when forwarding. Also, as I stated it's not just that I don't see the images. The only thing I do see when I hit forward are the headers. No body text at all. > Did you test this with somewhat more complex examples? I haven't spent time testing this with more complex examples. The messages I consistently see this bug with all have stylized text, an attached image, and are generated by the same service.
Here is the email that was produced the last time I forgot to forward as an attachment. Message-ID: <472F29E8.7050009@example.net> Date: Mon, 05 Nov 2007 07:34:16 -0700 From: Nobody you know <user@example.net> User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: [Removed to protect the innocent] Subject: [Fwd: SmartReceptionist Message] Content-Type: multipart/alternative; boundary="------------030604070704020409000800" This is a multi-part message in MIME format. --------------030604070704020409000800 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi, I'm not sure which one of you this is for. -------- Original Message -------- Subject: SmartReceptionist Message Date: Mon, 5 Nov 2007 07:03:05 -0700 From: Operations <operations@intelesure.com> To: <user@example.net> -- [signature snipped] --------------030604070704020409000800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> </head> <body bgcolor="#ffffff" text="#000000"> Hi,<br> <br> I'm not sure which one of you this is for.<br> <br> -------- Original Message -------- <table class="moz-email-headers-table" border="0" cellpadding="0" cellspacing="0"> <tbody> <tr> <th align="right" nowrap="nowrap" valign="baseline">Subject: </th> <td>SmartReceptionist Message</td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">Date: </th> <td>Mon, 5 Nov 2007 07:03:05 -0700</td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">From: </th> <td>Operations <a class="moz-txt-link-rfc2396E" href="mailto:operations@intelesure.com">&lt;operations@intelesure.com&gt;</a></td> </tr> <tr> <th align="right" nowrap="nowrap" valign="baseline">To: </th> <td><a class="moz-txt-link-rfc2396E" href="mailto:user@example.net">&lt;user@example.net&gt;</a></td> </tr> </tbody> </table> <br> <br> <br> <pre class="moz-signature" cols="72">-- [signature snipped] </pre> </body> </html> --------------030604070704020409000800--
You are right, this appears to be different from the tag corruption seen in bug 307023. While it is possible to corrupt the tags with specific character encoding and quoted-printable setting when forwarding from Original HTML, your observation also applies when the tags remain intact. Forwarding your message in the opening description from a local folder, with 8-bit setting from Original HTML does not corrupt the tags. Forwarding the message with the same settings, but from Simple HTML, results in an empty message as posted in comment #4. Another test: Using the forwarded message (8-bit, no tag corruption), then reforwarding it from Simple HTML does not produce the empty e-mail, thus it appears to be an issue with the original encoding of that message. Reproduced in TB branch release and nightly trunk version (WinXP, also seen in 2008041001 SeaMonkey/2.0a1pre), couldn't find any other possible duplicates, confirming.
Status: UNCONFIRMED → NEW
Component: General → MailNews: Composition
Ever confirmed: true
Product: Thunderbird → Core
QA Contact: general → composition
Version: unspecified → Trunk
A more detailed look at the messages shows an important difference in the nesting structure of the "multipart" constructs: (1) Messages causing tag corruption usually have the following structure: > multipart/alternative >> text/plain >> multipart/related >>> text/html, quoted-printable >>> image/gif (2) Your message has the following structure: > multipart/related >> multipart/alternative >>> text/plain >>> text/html, quoted-printable >> image/gif Note that in (1), the HTML text and the image are direct parts of the same multipart/related construct, thus tag corruption is triggered. For (2), the image is located outside of the plain/html-alternative part, thus no tag corruption occurs (which was actually stated in bug 307023 comment #8 as well), but the message is empty when forwarding from Simple HTML. Forwarding a message received in (2) from Original HTML reassembles it to the (1) structure, thus tag corruption may occur when reforwarding the message, but it works from Simple HTML now as well. This explains what I observed in comment #5. The message excerpt in comment #1 suggests a (1) format.
Summary: forward inline creates blank email → forward inline from Simple HTML view creates blank email
OS: Windows XP → All
Hardware: PC → All
Product: Core → MailNews Core
Hello, I am having the same issue in the Mac version of 2.0.0.17. Any suggestions to get it working?
I tested it with 2.0.0.16 und 3.0alpha3 and its still a problem. The workaround to switch from simple html to original html and then forward doesn't help.
(In reply to comment #8) > I tested it with 2.0.0.16 und 3.0alpha3 and its still a problem. The workaround > to switch from simple html to original html and then forward doesn't help. The only feasible work-around I've found is to forward as an attachment instead.
I've spent some time looking around the various MIME bugs here. It appears MIME is an area that needs a lot of help. Anyway, this particular problem seems very closely related to bug 13702 and the sample message attached to that bug has approximately the same mime structure as my original example. Also, the described behavior in bug 196180 is very similar to what I see when this bug is triggered. Bug 430697 also reports similar results but has a structure consistent with version 1 from comment #6. Of course, if bug 307023 does get fixed without causing other problems all of this mess might just go away.
Darn, bug 13702 should have been bug 137022. Sorry for any confusion!
If someone can come up with the minimal test case, that would likely help.
Flags: wanted-thunderbird3+
Keywords: helpwanted, qawanted
I now have a .eml file which I can use to repro this, but don't have the time to make it a minimal test case. The sender of the test case doesn't want it to be posted on a public bug tracker, but if someone wants to take on the job of trimming the .eml to the problematic bits, let me know, so we can get to a public .eml test case.
That seems a little too minimal: I don't see anything from it at all when it's opened, much less forwarded, unless I add a <body></body> around the QPed character, and when I do, I don't see anything in the forward whether I'm viewing Simple or Original HTML, so while you might have minimized two other bugs, I don't think you minimized this bug.
I tested it with 2.0.0.19 and when I open the blah.eml file I see in the body: ñ entering some text in an editor between <html> </html> displays the text in the opened email. Forwarding this email results in an empty body. In short: the example blah.eml (from comment #14) works for reproducing the problem.
According to bug 307023 comment #59, the issue reported here persists even after a fix has been checked in for that bug.
The .eml file from #14 seems to be buggy. When using that .eml file, forwarding does not work indeed, there resulting error is: ###!!! ASSERTION: not a UTF8 string: 'Error', file ../../dist/include/string/nsUTF8Utils.h, line 130 ###!!! ASSERTION: Input wasn't UTF8 or incorrect length was calculated: 'Error', file /mnt/archive/src/credativ/mozilla_head_branch/thunderbird_hg/src/mozilla/xpcom/string/src/nsReadableUtils.cpp, line 287 However when removing the ~n character and replacing it with some normal ascii text, forwarding inline works without problem. (Version: Thunderbird Shredder 28th Juli 2009)
Attached patch Patch that fixes the problem (obsolete) (deleted) — — Splinter Review
The problem was that some code that converts the raw mail data into a string had not enough information about the charset to use -> the conversion went wrong and an empty text was returned. This patch saves the full content type information in a separated member of nsMsgAttachedFile structure and allows the conversion code to find the right charset to use. @David I didn't see a reason why to use nsCString instead of char* here
Attachment #396712 - Flags: review?(bienvenu)
Assignee: nobody → tokoe
Status: NEW → ASSIGNED
Keywords: helpwanted, qawanted
I'd like to land this for b4, but with the current trunk, w/o this patch the attached test case works fine with forward inline, for both simple html and original html. So I don't have a test case that fails. I'll try what you suggest in #c18, but since it works already, I don't think that will help me reproduce the issue.
Hmm, I updated the repository here but still can reproduce the issue... Platform: Debian/Linux Version: mail/mailnews: 3791:78ad69924a87 mozilla: 26356:cbc05cbe8aa2
Comment on attachment 396712 [details] [diff] [review] Patch that fixes the problem OK, I can reproduce this problem, and the patch does fix it. We should, however, have a mozmill test for this, which shouldn't be too hard to do given that you have a test case...
Attachment #396712 - Flags: superreview?(bugzilla)
Attachment #396712 - Flags: review?(bienvenu)
Attachment #396712 - Flags: review+
Comment on attachment 396712 [details] [diff] [review] Patch that fixes the problem This looks good, thanks. We really should have a test for it - a mozmill test should be fairly easy as we've already got tests that check reply and forward (under content-policy), and tests that check the content of composed messages (under composition). If you need any help, then feel free to email me direct or comment here.
Attachment #396712 - Flags: superreview?(bugzilla) → superreview+
Flags: in-testsuite?
Attached file No-quite-minimal testcase (obsolete) (deleted) —
Here is a less minimal testcase, but that still triggers this bug with Thunderbird 3.1.9.
Attachment #517800 - Attachment mime type: application/octet-stream → message/rfc822
This bug and other similar cases (foward inline fails with some mails) seems to caused by the HTML tag generated by Outlook. The tag looks like <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = xmlns:o=3D"urn:schemas-microsoft-com:office:office" = xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = xmlns=3D"http://www.w3.org/TR/REC-html40"> Changing all this with a simple <html> will make inline forwarding work (I've tried 3 different testcases and they all work).
(In reply to Chris from comment #0) > Steps to Reproduce: > 1. View message body as simple html > 2. Choose message forward as inline > 3. Observe misssing message body in the compose window > Actual Results: > headers but no body <html> tag of HTML mail. > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > xmlns:x=3D"urn:schemas-microsoft-com:office:excel" = > xmlns=3D"http://www.w3.org/TR/REC-html40"> (In reply to intendentedelleacque from comment #25) > Changing all this with a simple > <html> > will make inline forwarding work (I've tried 3 different testcases and they all work). Same problem as bug 313401 which was originally reported for same kind of HTML mail made by MS's software. Bug opener of that bug had referred to "changing <html xmlns...> to <html> is a simple workaround" since initial of bug open.
(In reply to Blake Winton (:bwinton - Thunderbird UX) from comment #14) > Created attachment 365509 [details] > A minimal test case, from David's .eml file. HTML tag is <html>. Actually minimum test case for this bug? Test mail you attached: (a) Also mail of not-well-formed multipart/related+multipart/alternative. part 1: multipart/related (b) no sub-part other than multipart/alternative for message body, even though multiparte/related. part 1.1: multipart/alternative (c) no text/plain part in multipart/alternative part 1.1.1: text/html (d) quoted-printable (e) =F1 in HTML sorce, which may produce charset relevant bug (f) <html> (no attribete in <html> tag) I also couldn't reproduce this bug's original problem, which is problem only in "Simple HTML mode && Forward in inline", with your "minimul" test case. (In reply to Tobias Koenig from comment #19) > Created attachment 396712 [details] [diff] [review] > Patch that fixes the problem (In reply to David :Bienvenu from comment #22) > Comment on attachment 396712 [details] [diff] [review] > Patch that fixes the problem > OK, I can reproduce this problem, and the patch does fix it. We should, Patch for which problem in this bug report at B.M.O? For following assertion of comment #18 with test mail attache by Blake Winton? > ###!!! ASSERTION: not a UTF8 string: 'Error', file ../../dist/include/string/nsUTF8Utils.h, line 130 Or for original bug report of coment #0 with mail data pasted in comment #0? If patch is for the assertion in comment #18 only instead of original problem of this bug, I believe this bug should be closed as dup of bug 313401 and the proposed patch to this bug should be processed in different bug for the assertion with the *minimal* test case.
Anyone fancy verifying this bug still exists, updating the patch, and maybe providing a unit test? We already have some mozmill tests for message forwarding (in http://mxr.mozilla.org/comm-central/source/mail/test/mozmill/composition/), so hopefully we can base off of those.
Well, I am not really sure how to help but on Thunderbird 15.0.1, I have this bug, for some messages. Forward as inline give sometimes blank email, forward as attachment is the bypass for me. Ubuntu 3.2.0-31-generic #50-Ubuntu SMP Fri Sep 7 16:16:45 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux Thunderbird 15.0.1 Philip
Attached patch proposed fix - unbitrotted (obsolete) (deleted) — — Splinter Review
Unbitrotted patch, with a mozmill test. Unfortunately, it doesn't fix the problem for the test case in attachment 517800 [details], and attachment 365509 [details] seems WFM (adding <body> around the char) I suspect attachment 517800 [details] is more about bug 313401 though. Tobias: did you have a local test case for this?
Attachment #396712 - Attachment is obsolete: true
Attachment #673725 - Flags: feedback?(tokoe)
I found this Googling the issue. I can confirm what https://bugzilla.mozilla.org/show_bug.cgi?id=394322#c25 reports: the xmlns from Microsoft (looks like Outlook-via-Word-engine generated stuff to me) is causing the problem for us. I can also confirm that the issue is on-forward only. It doesn't affect reply (and this is the workaround we are applying now).
This bug has been causing a lot of problems for my users. Several of our biggest customers seem to be using outlook+word for all their e-mail. Contrary to the description of this bug, we see the problem with forwarding from both "Simple HTML" view and "Original HTML" view.
Assignee: tokoe → nobody
Attachment #673725 - Flags: feedback?(tokoe)
The assignee has reassigned to nobody, thus reinstating "NEW" status.
Status: ASSIGNED → NEW
Whiteboard: [has draft patch]
Just hit this 7 year old bug. Interestingly using Options > Quote Message inserted visible content of the forwarded message, so is a workaround of sorts.
(In reply to intendentedelleacque from comment #25) > This bug and other similar cases (foward inline fails with some mails) seems > to caused by the HTML tag generated by Outlook. > > The tag looks like > > <html xmlns:v=3D"urn:schemas-microsoft-com:vml" = > > xmlns:o=3D"urn:schemas-microsoft-com:office:office" = > > xmlns:w=3D"urn:schemas-microsoft-com:office:word" = > > xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" = > > xmlns=3D"http://www.w3.org/TR/REC-html40"> > > Changing all this with a simple > > <html> > > will make inline forwarding work (I've tried 3 different testcases and they > all work). This bus still alive in to 31.2.0
What is difference of this bug from bug 313401 where problem is clearly isolated?
(In reply to Magnus Melin from comment #30 > proposed fix - unbitrotted I believe that patch is better to be proposed in bug 496723 or bug 313401.
I had a big problem replying to some of the emails my mom sended me (from Apple Mail). All replays she received and the saved replays in my sendbox were empty. So I stumbled across this Bug and tried out to include the attached patch into my TB 35 build. And voilà, it worked, no empty replays anymore. I know, this Bug is not exactly about my issue, but nevertheless, this patch fixed my issue as well. I remember, that I had this problem sometimes with older TB versions too. And some googleing revealed, I'm not the only one seeing this with some emails. So, I would love to see this bug fixed, so this issue will never ever (hopefully) occur. :-)
Can you attach a test case (.eml) that the patch fixes?
(In reply to Magnus Melin from comment #39) > Can you attach a test case (.eml) that the patch fixes? No, sorry, it doesn't work to make a testcase out of this affected email. :-(
Doesn't work as in a save .eml doesn't reproduce, or that it contains personal details? You can copy paste the mail content from the mailbox too if that reproduces. And edit away personal details of course...
(In reply to Magnus Melin from comment #41) > Doesn't work as in a save .eml doesn't reproduce, or that it contains > personal details? You can copy paste the mail content from the mailbox too > if that reproduces. And edit away personal details of course... I save the message as .eml, edit all personal datas out, open it in TB and reply to it with a non-patched build. But than it works as expected.
Hello, Same problem in TB 31.8. I haven't got the problem if I reply to the mail. Have you an idea of what's happen ? Alex
Verifying that this is still an issue as of TB 38.2. The problem appears to be with Microsoft-generated Base64 encoded emails. At least, that's the only place I've seen it.
Attachment #517800 - Attachment mime type: message/rfc822 → text/plain
Flags: in-testsuite?
This problem is still evident in TB 60.0b7 beta. The work around is to Quote Message before sending I don't like it, but it is all we have unless we migrate to Outlook.
This problem is still evident in TB 60.0b7 beta. The work around is to Quote Message before sending I don't like it, but it is all we have unless we migrate to Outlook. If someone would make mail.forward.inline a default value to quote message, like mail.reply.inline, then that would be an easy fix.
Attached patch bug394322_fwd_simple_html_blank.patch - rebased (obsolete) (deleted) — — Splinter Review
Rebased, without the unnecessary changes to the IDL and without the test. As far as I can see, this fixes nothing, certainly not the test case from attachment 8987246 [details].
So the problem is quite obvious: mimedrft.cpp searches for a <HTML> tag without attributes. If not found, things stop working: https://dxr.mozilla.org/comm-central/search?q=html_tag+%3D+PL_strcasestr(*body%2C+%22%3CHTML%3E%22)%3B&redirect=false
Attached patch 394322-html-tag.patch (obsolete) (deleted) — — Splinter Review
This fixes various forwarding issues reported here, in bug 313401 and all the other duplicates. Test case in attachment 8987246 [details] from bug 1470210. I'll add a test a little later. I don't understand what the original patch was on about.
Attachment #365509 - Attachment is obsolete: true
Attachment #517800 - Attachment is obsolete: true
Attachment #673725 - Attachment is obsolete: true
Attachment #8987249 - Attachment is obsolete: true
Attachment #8987262 - Flags: review?(acelists)
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Summary: forward inline from Simple HTML view creates blank email → forward inline from Simple HTML view creates blank email if html tag as attribution
Summary: forward inline from Simple HTML view creates blank email if html tag as attribution → forward inline from Simple HTML view creates blank email if html tag has attribution
Summary: forward inline from Simple HTML view creates blank email if html tag has attribution → forward inline from Simple HTML view creates blank email if html tag has attribution (typically originating from MS software)
Looking at the alleged duplicate bug 1381234 most of the test cases there have HTML bodies without <html> tag. So forwarding used to fail for "simple" HTML view, and now fails for "simple" and "original" HTML view. I think we need to fix this here as well, since otherwise many people won't be happy when forwarding.
Attached file multipart-related.eml (deleted) —
Here a test message where the HTLM contains no <html> tag :-( The patch doesn't address this yet.
OK, the problem is this: Due to some MIME defectiveness, the HTML we're processing is: <div>hi there, the HTML here has no HTML tag, only div.<br> <img alt="" src="mailbox:///C:/Users/jorgk/AppData/Roaming/Thunderbird/Profiles/ kp2r4jae.Testing%202/Mail/Local%20Folders/June%202018?number=16&part=1.2&filenam e=klee.gif"><br> </div> <html><head> <meta http-equiv="content-type" content="text/html; "></head><body></body></html> So jolly good, there is a second empty HTML tag and that's the one we're appending as HTML to out forwarded message :-( That was already observed in bug 1470210 comment #11.
Attached patch 394322-html-tag.patch (v2) (obsolete) (deleted) — — Splinter Review
OK, this fixes both cases now: HTML part has <html attr> tag with attribute and HTML part has no <html> tag. It would of course be cleaner to find the root cause for the second empty <html> tag.
Attachment #8987262 - Attachment is obsolete: true
Attachment #8987262 - Flags: review?(acelists)
Attachment #8987264 - Flags: review?(acelists)
Attached patch 394322-html-tag.patch (v3) (obsolete) (deleted) — — Splinter Review
OK, here comes the good fix. Fixes both cases: <html attr> and no HTML tag. The observation in bug 1470210 comment #11 was that we get called there with empty HTML, and parsing and serialising blows this up to: <html><head><meta http-equiv="content-type" content="text/html; charset="></head><body></body></html> which is undesired. So suppressing that makes (v1) work in both cases.
Attachment #8987264 - Attachment is obsolete: true
Attachment #8987264 - Flags: review?(acelists)
Attachment #8987265 - Flags: review?(acelists)
Attached patch 394322-tests.patch (obsolete) (deleted) — — Splinter Review
No new test required, we already test something similar. I've just tweaked the data and added tests to run in "simple" HTML mode. You can apply the test patch first and see that all those test fail.
Attachment #8987286 - Flags: review?(acelists)
Attached patch 394322-html-tag.patch (v4) (obsolete) (deleted) — — Splinter Review
OK, surveying depended bugs I came across bug 670884 and attachment 545346 [details] where text before the HTML tag is not included in the forward since only content after the <html> tag is copied. To fix this, I'm going back to (v2) where I only looked for "<HTML" at the beginning. That fixes the said bug. I'll add a test for it :-(
Attachment #8987265 - Attachment is obsolete: true
Attachment #8987265 - Flags: review?(acelists)
Attachment #8987287 - Flags: review?(acelists)
Attached patch 394322-tests.patch (v2) (deleted) — — Splinter Review
More tests for content before the <html> tag.
Attachment #8987286 - Attachment is obsolete: true
Attachment #8987286 - Flags: review?(acelists)
Attachment #8987288 - Flags: review?(acelists)
Attached patch 394322-html-tag.patch (v4b) (obsolete) (deleted) — — Splinter Review
Same thing, but merging two if-statements. https://treeherder.mozilla.org/#/jobs?repo=try-comm-central&revision=98c4a065e4cab9bbd19060916256198a67b21767
Attachment #8987287 - Attachment is obsolete: true
Attachment #8987287 - Flags: review?(acelists)
Attachment #8987289 - Flags: review?(acelists)
Both tries are green, but let's go with the most recent version.
Comment on attachment 8987289 [details] [diff] [review] 394322-html-tag.patch (v4b) Review of attachment 8987289 [details] [diff] [review]: ----------------------------------------------------------------- I'll comment on my own patch to explain the changes. ::: mailnews/mime/src/mimeTextHTMLParsed.cpp @@ +83,5 @@ > return 0; > > nsString& rawHTML = *(me->complete_buffer); > + if (rawHTML.IsEmpty()) > + return 0; I noticed that this gets called with an empty string after getting called with the HTML of the message. That led to <html><head><meta http-equiv="content-type" content="text/html; charset="></head><body></body></html> being appended which upset the logic in mimedrft.cpp. ::: mailnews/mime/src/mimedrft.cpp @@ +664,5 @@ > bool htmlEdit = (composeFormat == nsIMsgCompFormat::HTML); > char *newBody = NULL; > char *html_tag = nullptr; > + if (*body && PL_strncmp(*body, "<HTML", 5) == 0) > + html_tag = PL_strchr(*body, '>') + 1; Initially this looked for <HTML> and thus missing <HTML attr=xxx>. In another version of the patch I looked for <HTML and then the closing >, but that misses to include content before the <HTML> tag, see bug 670884. Now of course we might miss the <HTML> that, meaning that it will be copied to the forwarded message, but that doesn't matter. Gecko's HTML parser will sort out the "HTML soup" as Ben calls it here https://dxr.mozilla.org/comm-central/search?q=HTML+soup&redirect=false
Comment on attachment 8987289 [details] [diff] [review] 394322-html-tag.patch (v4b) Review of attachment 8987289 [details] [diff] [review]: ----------------------------------------------------------------- Thanks ::: mailnews/mime/src/mimedrft.cpp @@ +663,5 @@ > { > bool htmlEdit = (composeFormat == nsIMsgCompFormat::HTML); > char *newBody = NULL; > char *html_tag = nullptr; > + if (*body && PL_strncmp(*body, "<HTML", 5) == 0) Should this only catch uppercase HTML? Or am I reading it wrong?
Attachment #8987289 - Flags: review?(acelists) → review+
Comment on attachment 8987288 [details] [diff] [review] 394322-tests.patch (v2) Review of attachment 8987288 [details] [diff] [review]: ----------------------------------------------------------------- Great, thanks for expanding the tests. ::: mail/test/mozmill/composition/content-utf8-alt-rel2.eml @@ +22,5 @@ > +Content-Type: text/html; charset=UTF-8 > +Content-Transfer-Encoding: 8bit > + > +áóúäöüß<br> > +<html> So it seems we have also lowercase 'html' to process ? @@ +23,5 @@ > +Content-Transfer-Encoding: 8bit > + > +áóúäöüß<br> > +<html> > + <!-- This also needs to work when the content before the html tag :-( --> ...work when there IS content... ? ::: mail/test/mozmill/composition/test-forward-utf8.js @@ +117,4 @@ > } > > function teardownModule() { > + Services.prefs.clearUserPref("mailnews.display.html_as"); I think you could clear the pref inside test_utf8_forwarding_from_via_folder() in case there will be more tests that rely on the default again.
Attachment #8987288 - Flags: review?(acelists) → review+
Attached patch 394322-html-tag.patch (v4c) (deleted) — — Splinter Review
Grrrr, I was meant to use PL_strncasecmp() :-( - Tests still pass. That just shows what I said at the end of comment #68: Whether we detect and strip the tag doesn't matter much at all. If we strip it, we still copy the closing tag </html> over, to the HTML we hand to Gecko is messy either way.
Attachment #8987289 - Attachment is obsolete: true
Attachment #8987340 - Flags: review+
(In reply to :aceman from comment #70) > I think you could clear the pref inside > test_utf8_forwarding_from_via_folder() in case there will be more tests that > rely on the default again. Are you sure? I never know what happens when things fail partially. At least teardownModule() would get run to leave a clean slate for subsequent tests.
Pushed by mozilla@jorgk.com: https://hg.mozilla.org/comm-central/rev/c740f4505eaf Fix various forwarding issues: <html attr>, without <html>, content before <html>. r=aceman
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Attachment #8987340 - Flags: approval-comm-esr60+
Attachment #8987340 - Flags: approval-comm-beta+
Landed folded patch. Comment in test message corrected, bug reset pref left in teardownModule() since the first failure aborts and pref wouldn't be reset (I tested that).
Whiteboard: [has draft patch]
Target Milestone: --- → Thunderbird 62.0
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: