4.54 KB, message/rfc822
3.63 KB, message/rfc822
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 (mail: version 0.6 (20040502)) MS-Outlook 2000 defaults to sending HTML emails. Most people also use MS-Word to compose the mail. When they send a HTML mail, it will contain this HTML code on every newline: <![if !supportEmptyParas]> <![endif]> It doesn't show in TB though so it works fine. However, when replying to such a message, TB will change the above HTML to this: <!--[if !supportEmptyParas]--> <!--[endif]--> It adds -- after <! and before >. When viewing the reply in TB/Mozilla it all looks fine. However, when viewing the reply back in Outlook 2000 it will show the code in the message, so on every newline you will see this in Outlook: <!--[if !supportEmptyParas]--> <!--[endif]--> Reproducible: Always Steps to Reproduce: 1. Open Outlook (I tested 2000 but presumabely it works with all versions) 2. Go to extra -> options -> email and set it to HTML and 'use Word' 3. Send an email with a couple of newlines to you Mozilla account 4. Open the mozilla account and reply to the message (reply inline) 5. View the reply in Outlook 2000 Actual Results: Mail send out the following HTML code on the newlines of the original message <!--[if !supportEmptyParas]--> <!--[endif]--> Expected Results: Mail should have left the original HTML intact and sent this: <!--[if !supportEmptyParas]--> <!--[endif]--> I have tested this with TB 0.7 on Win98, Mozilla 1.6 on Win2000 when replying to Outlook 2000 on Win2000. I presume it happens with other versions too.
Oops, I made a slight mistake in my first comment (and I see no way to edit it). The expected result should ofcourse be this (without the --'s): <![if !supportEmptyParas]> <![endif]>
Attachment #151017 - Attachment mime type: text/plain → message/rfc822
Attachment #151018 - Attachment mime type: text/plain → message/rfc822
I can confirm this behavior with Mozilla 1.6. I do not understand why those dashes are *not* in the original, since all the other conditional junk in that original document have the dashes to start with -- it appears that the dashes are the "correct" thing to do. MS's HTML ways are inscrutable. See bug 192557: a new approach to HTML message editing is taking place which may change this behavior very much; that conditional junk may be simply eliminated, which makes a lot of sense to me... (It does change it very much in 1.8a builds with the patch from that bug -- I'm using 1.8a2-0610 -- but that patch has some problems, so I don't know how it's going to shake out.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
According to the following microsoft document about all the HTML junk (and a filter plugin for it) both <!--[ ]--> as well as <![ ]> are valid. http://office.microsoft.com/assistance/preview.aspx?AssetID=HA010549981033&CTT=6&Origin=EC010553071033 <!--[ ]--> are so-called 'downlevel conditional comments' and <![ ]> are 'uplevel conditional comments'.
With the new patch for bug 192557, the original behavior is back in current 1.8a2 builds: the HTML structure of the original is being maintained in the reply. This bug has not been addressed.
*** Bug 231583 has been marked as a duplicate of this bug. ***
Could it be, that Thunderbird/Mozilla creates valid W3C HTML 4.01?
It doesn't. It just mangles the broken but still correctly viewable MS-HTML into something unviewable because it adds the -- in the tag below: <!--[if !supportEmptyParas]--> <!--[endif]--> Just copy/paste the sources of the e-mails above in a html file and check for yourself.
sorry for the spam. making bugzilla reflect reality as I'm not working on these bugs. filter on FOOBARCHEESE to remove these in bulk.
Assignee: sspitzer → nobody
Product: Core → MailNews Core
I would plead to let TB remove all HTML comment in outgoing emails. Simple thing to do.
You need to log in before you can comment on or make changes to this bug.