Open Bug 243708 Opened 21 years ago Updated 3 years ago

when replying to an html message sent by MS OE, Mozilla drops 'charset' parameter in meta tag inside <blockquote>

Categories

(MailNews Core :: Internationalization, defect)

x86
Linux
defect

Tracking

(Not tracked)

People

(Reporter: jshin1987, Unassigned)

Details

(Keywords: intl)

This is hardly a bug of mozilla, but still it gets in the way of promoting Mozilla-mail/Thunderbird to those the majority of whose correspondents use MS OE. When replying to a message like 'case A' (sent by MS OE), Mozilla produces the html body like case B. If you look at case B carefully, Mozilla makes it clear that the charset used is UTF-8 in two places (Content-Type header of the message part and 'the outer most' meta tag of the html body). However, it doesn't inside '<blockquote>'. Somehow, it drops 'charset=UTF-8' inside <blockquote> as reproduced here again: <blockquote cite="mid000c01c43ac0$cefd5fe0$b81ef88f@aragorn" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> Unfortunately, MS OE picks up the 'inner most' declaration (inside <blockquote>) and interprets the message body not as UTF-8 but as something else (that seems to be the default 'mail view encoding' Two fixes can be considered: 1) excluse everything that comes before <body> when blockquoting. However, that may be risky. 2) do not drop 'charset=UTF-8' inside <blockquote> case A: --------Cut------------Here-------- ------=_NextPart_000_0009_01C43B0C.3EDB6AF0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EA=B0=80=EB=82=98=EB=8B=A4=E3=85=8F=EB=9D=BC=EB=A7=8812334434343=EA=B0=80= =EB=82=98=EB=8B=A4=EB=9E=84 ------=_NextPart_000_0009_01C43B0C.3EDB6AF0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dutf-8"> <META content=3D"MSHTML 6.00.3790.118" name=3DGENERATOR> <STYLE></STYLE> </HEAD><FONT face=3DArial><FONT size=3D2> <BODY> <DIV>=EA=B0=80=EB=82=98=EB=8B=A4=E3=85=8F=EB=9D=BC=EB=A7=8812334434343=EA= =B0=80=EB=82=98=EB=8B=A4=EB=9E=84</DIV> <DIV>&nbsp;</DIV></BODY></HTML></FONT></FONT> ------=_NextPart_000_0009_01C43B0C.3EDB6AF0-- --------Cut------------Here-------- case B : -------Cut------Here------------ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> <title></title> </head> <body> bioif(imap4) wrote:<br> <blockquote cite="mid000c01c43ac0$cefd5fe0$b81ef88f@aragorn" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta content="MSHTML 6.00.3790.118" name="GENERATOR"> <style></style> <font face="Arial"><font size="2"> ...... 8bit body omitted here.... --------Cut------------Here--------
<blockquote cite="mid000c01c43ac0$cefd5fe0$b81ef88f@aragorn" type="cite"> <meta http-equiv="Content-Type" content="text/html; "> <meta content="MSHTML 6.00.3790.118" name="GENERATOR"> <style></style> We send that out? That's severely broken, <meta> is a a <head> tag, not for <body>. MS is just right to think that the msg doesn't make sense and fall back to default.
(In reply to comment #1) > We send that out? That's severely broken, <meta> is a a <head> tag, not for > <body>. Ok, it's broken and we should fix it. > MS is just right to think that the msg doesn't make sense and > fall back to default. However, I'd not say they're right either. Neither are they wrong. The way they parse text/html part (they could just ignore the innermost meta tag because, as you wrote, it doesn't belong there and just honor one of outer charset type declarations) happens to be 'incompatible' with Mozilla's (broken) way of quoting a 'html' message in an html message.
Status: NEW → ASSIGNED
Product: MailNews → Core
Product: Core → MailNews Core
reset QA (was empty)
QA Contact: i18n
does this still reproduce?
Assignee: jshin1987 → nobody
Status: ASSIGNED → NEW
Yes, it still reproduces.
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.