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

RESOLVED FIXED in Thunderbird 62.0

Status

defect
--
major
RESOLVED FIXED
12 years ago
11 months ago

People

(Reporter: bugzilla, Assigned: jorgk)

Tracking

Trunk
Thunderbird 62.0
Bug Flags:
wanted-thunderbird3 +

Thunderbird Tracking Flags

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

Details

Attachments

(3 attachments, 11 obsolete attachments)

1.38 KB, text/plain
Details
4.70 KB, patch
aceman
: review+
Details | Diff | Splinter Review
6.55 KB, patch
jorgk
: review+
Details | Diff | Splinter Review
Reporter

Description

12 years ago
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--

Comment 1

12 years ago
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 [...]

Comment 2

11 years ago
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?
Reporter

Comment 3

11 years ago
(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.
Reporter

Comment 4

11 years ago
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--

Comment 5

11 years ago
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

Comment 6

11 years ago
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

Updated

11 years ago
OS: Windows XP → All
Hardware: PC → All
Product: Core → MailNews Core

Comment 7

11 years ago
Hello, I am having the same issue in the Mac version of 2.0.0.17.  Any suggestions to get it working?

Comment 8

11 years ago
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.
Reporter

Comment 9

11 years ago
(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.
Reporter

Comment 10

11 years ago
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.
Reporter

Comment 11

11 years ago
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.

Comment 16

10 years ago
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.

Comment 17

10 years ago
According to bug 307023 comment #59, the issue reported here persists even after a fix has been checked in for that bug.

Comment 18

10 years ago
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)

Comment 19

10 years ago
Posted patch Patch that fixes the problem (obsolete) — 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

Comment 20

10 years ago
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.

Comment 21

10 years ago
Hmm, I updated the repository here but still can reproduce the issue...

Platform: Debian/Linux
Version: mail/mailnews: 3791:78ad69924a87
         mozilla: 26356:cbc05cbe8aa2

Comment 22

9 years ago
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?
Posted file No-quite-minimal testcase (obsolete) —
Here is a less minimal testcase, but that still triggers this bug with Thunderbird 3.1.9.

Updated

8 years ago
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.

Comment 29

7 years ago
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
Posted patch proposed fix - unbitrotted (obsolete) — 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)

Comment 31

6 years ago
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).

Comment 32

5 years ago
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.

Updated

5 years ago
Assignee: tokoe → nobody
Attachment #673725 - Flags: feedback?(tokoe)

Comment 33

5 years ago
The assignee has reassigned to nobody, thus reinstating "NEW" status.
Status: ASSIGNED → NEW
Whiteboard: [has draft patch]

Comment 34

5 years ago
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.

Comment 35

5 years ago
(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.

Comment 38

5 years ago
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?

Comment 40

5 years ago
(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...

Comment 42

5 years ago
(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.

Comment 43

4 years ago
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.
Assignee

Updated

2 years ago
Attachment #517800 - Attachment mime type: message/rfc822 → text/plain
Assignee

Updated

2 years ago
Duplicate of this bug: 1381234
Flags: in-testsuite?

Comment 46

11 months ago
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.

Comment 47

11 months ago
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.
Assignee

Updated

11 months ago
Duplicate of this bug: 1470210
Assignee

Updated

11 months ago
See Also: 313401
Duplicate of this bug: 313401
Assignee

Updated

11 months ago
Duplicate of this bug: 1154105
Assignee

Comment 51

11 months ago
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].
Assignee

Comment 52

11 months ago
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
Assignee

Comment 53

11 months ago
Posted patch 394322-html-tag.patch (obsolete) — 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

Updated

11 months ago
Assignee: nobody → jorgk
Status: NEW → ASSIGNED
Assignee

Updated

11 months ago
Summary: forward inline from Simple HTML view creates blank email → forward inline from Simple HTML view creates blank email if html tag as attribution
Assignee

Updated

11 months ago
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
Assignee

Updated

11 months ago
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)
Assignee

Comment 55

11 months ago
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.
Assignee

Comment 56

11 months ago
Here a test message where the HTLM contains no <html> tag :-(

The patch doesn't address this yet.
Assignee

Comment 57

11 months ago
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.
Assignee

Comment 58

11 months ago
Posted patch 394322-html-tag.patch (v2) (obsolete) — 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)
Assignee

Comment 59

11 months ago
Posted patch 394322-html-tag.patch (v3) (obsolete) — 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)
Assignee

Comment 60

11 months ago
Posted patch 394322-tests.patch (obsolete) — 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)
Assignee

Updated

11 months ago
See Also: 496723
Duplicate of this bug: 496723
Assignee

Updated

11 months ago
Duplicate of this bug: 670884
Assignee

Comment 64

11 months ago
Posted patch 394322-html-tag.patch (v4) (obsolete) — 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)
Assignee

Comment 65

11 months ago
More tests for content before the <html> tag.
Attachment #8987286 - Attachment is obsolete: true
Attachment #8987286 - Flags: review?(acelists)
Attachment #8987288 - Flags: review?(acelists)
Assignee

Comment 66

11 months ago
Posted patch 394322-html-tag.patch (v4b) (obsolete) — 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)
Assignee

Comment 67

11 months ago
Both tries are green, but let's go with the most recent version.
Assignee

Comment 68

11 months ago
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 69

11 months ago
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 70

11 months ago
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+
Assignee

Comment 71

11 months ago
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+
Assignee

Comment 72

11 months ago
(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.

Comment 73

11 months ago
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
Last Resolved: 11 months ago
Resolution: --- → FIXED
Assignee

Updated

11 months ago
Attachment #8987340 - Flags: approval-comm-esr60+
Attachment #8987340 - Flags: approval-comm-beta+
Assignee

Comment 74

11 months ago
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.