Open Bug 247313 Opened 20 years ago Updated 2 years ago

HTML being changed when replying to Outlook HTML email composed in Word

Categories

(MailNews Core :: MIME, defect)

x86
Windows 98
defect

Tracking

(Not tracked)

People

(Reporter: s.marechal, Unassigned)

References

Details

Attachments

(2 files)

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]>&nbsp;<![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]-->&nbsp;<!--[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]-->&nbsp;<!--[endif]-->


Expected Results:  
Mail should have left the original HTML intact and sent this:
<!--[if !supportEmptyParas]-->&nbsp;<!--[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]>&nbsp;<![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. ***
Product: MailNews → Core
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]-->&nbsp;<!--[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
QA Contact: mime
Product: Core → MailNews Core
I would plead to let TB remove all HTML comment in outgoing emails. Simple thing to do.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: