Closed
Bug 858982
Opened 12 years ago
Closed 12 years ago
Glyfs in 8859-2 html mail rendered incorrectly
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 855329
People
(Reporter: terraluna977, Unassigned)
Details
Attachments
(1 file)
2.12 MB,
image/jpeg
|
Details |
User Agent: Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17
Build ID: 20130331202235
Steps to reproduce:
Received an email with ISO 8859-2 encoding, generated in Thunderbird 17.0.4, with both plain text and html contents.
Tested on Linux host, Debian.
Actual results:
Seamonkey releases past 2.15.2 have problems displaying the letters.
I attach a snapshot from the display.
The window on the LEFT is a print preview from the Seamonkey mail, and is correctly rendering the Polish letters. The window on the right shows the mail as displayed by Seamonkey.
Displaying the html source in 8859-2 shows correct text.
So it is just mail contents displayed incorrectly.
Problem seen on 2.16, 2.16.2, 2.17
Reporter | ||
Updated•12 years ago
|
Component: General → MailNews: Message Display
Reporter | ||
Comment 1•12 years ago
|
||
Exactly same problem visible on WinXP as well.
Comment 2•12 years ago
|
||
This sounds like a duplicate of bug 594646.
1. Hit Ctrl+U (View Source) on one offending email, scroll down to the HTML part (normally starting with <html> or <HTML>) then look at the <meta> tags. If you see one with http-equiv="Content-Type" at the end and content= before it, then please RESOLVE this bug as a DUPLICATE of 594646.
2. I don't know when (or if) bug 594646 will be fixed, but in the meantime the HTML text will be displayed correctly by doing either of the following:
a) "View → Message Body As → Simple HTML", or
b) Opening a message-compose window to reply to the message. (You can close that window by Ctrl+W or by clicking the little X at top right if you don't need to reply.)
Of course, you can still use "Original HTML" viewing on the messages not affected by the bug, including all plaintext messages.
Flags: needinfo?(terraluna977)
Reporter | ||
Comment 3•12 years ago
|
||
I can confirm that both workarounds work as described, so it may be the same issue as 594646.
I am not sure if the HTML attachment is exactly conforming to your description, so here I submit it for verification:
/...
--------------090704000504090006080804
Content-Type: multipart/related;
boundary="------------070608010208000209080607"
--------------070608010208000209080607
Content-Type: text/html; charset=ISO-8859-2
Content-Transfer-Encoding: 8bit
<html>
<head>
<title>Komunikaty Ottawskie - 20 marca 2013</title>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-2">
<meta content="MSHTML 6.00.6000.17095" name="GENERATOR">
</head>
<body alink="#EE0000" bgcolor="#ffffff" link="#0000EE" text="#000000"
vlink="#551A8B">
<br>
/...
Status: UNCONFIRMED → RESOLVED
Closed: 12 years ago
Flags: needinfo?(terraluna977)
Resolution: --- → DUPLICATE
Comment 4•12 years ago
|
||
(In reply to Woody Suwalski from comment #3)
> I can confirm that both workarounds work as described, so it may be the same
> issue as 594646.
> I am not sure if the HTML attachment is exactly conforming to your
> description, so here I submit it for verification:
[...]
> <meta http-equiv="Content-Type" content="text/html;
> charset=ISO-8859-2">
[...]
well, no, here http-equiv appears first, so it isn't bug 594646. But no matter, this isn't the first case I've met either. This just might be a duplicate of bug 855329.
Reporter | ||
Comment 5•11 years ago
|
||
Tested OK in Seamonkey 2.22
You need to log in
before you can comment on or make changes to this bug.
Description
•