822641 - Accented characters in ISO-8859-2 messages displayed wrongly in Thunderbird 19

Status: RESOLVED DUPLICATE of bug 594646

(Thunderbird :: Message Reader UI, defect)

Description

[Szabolcs Hubai (:xabolcs)]

Attachment: htmltest.eml - html draft with accented characters

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20121217 Firefox/19.0
Build ID: 20121217042016

Steps to reproduce:

I got lot of mails with accented characters, and started with Earlybird 19.0a2 some of them are wrongly decoded. 
Also happen if message is opened in new message window or in new tab.
See attached draft message and picture.


If I open those mails with release Thunderbird (currently: 17) characters are displayed correctly.
It doesn't happen in Forward, Answer, Reply window.

If the wrongly decoded message is forwarded then the new message will be displayed correctly.
If the wrongly decoded message is "Edit as new ..." and sent, 
then the new message would trigger the wrong behavior.


Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20121217 Thunderbird/19.0a2 ID:20121217042002 CSet: 90249d084a38


Actual results:

Example strings:

"Mindenkinek kellemes karĂĄcsonyi Ăźnnepeket kĂ­vĂĄnok"
"dĹlt"
"ĂĄrvĂ­ztĹąrĹ tĂźkĂśrfĂşrĂłgĂŠp"


Expected results:

Example strings:

"Mindenkinek kellemes karácsonyi ünnepeket kívánok"
"dőlt"
"árvíztűrő tükörfúrógép"

Comment 1

[Szabolcs Hubai (:xabolcs)]

Attachment: htmltest.eml.png - draft opened with Earlybird 19.0a2

A screenshot about the wrong behavior.

The Earlybird was:
Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20121217 Thunderbird/19.0a2 ID:20121217042002 CSet: 90249d084a38

Comment 2

[Joshua Cranmer [:jcranmer]]

Okay, this is definitely still happening on trunk.

The key part of the message, naturally, is the following:
    <meta http-equiv="content-type" content="text/html;
     charset=ISO-8859-2">

If you remove the line break in the attribute, the message works correctly. Otherwise, you get ISO-8859-2-to-UTF-8-to-ISO-8859-2 mojibake.

Comment 3

[Joshua Cranmer [:jcranmer]]

This is the same underlying issue as bug 594646, essentially: there's a <meta> tag, but libmime already converted it to UTF-8, so the <meta> tag should be ignored, and our logic in libmime doesn't do the "ignore" part properly.