Closed Bug 858982 Opened 11 years ago Closed 11 years ago

Glyfs in 8859-2 html mail rendered incorrectly

Categories

(SeaMonkey :: MailNews: Message Display, defect)

SeaMonkey 2.17 Branch
x86
Linux
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 855329

People

(Reporter: terraluna977, Unassigned)

Details

Attachments

(1 file)

Attached image seamonkey.jpg
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
Component: General → MailNews: Message Display
Exactly same problem visible on WinXP as well.
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)
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: 11 years ago
Flags: needinfo?(terraluna977)
Resolution: --- → DUPLICATE
(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.
Tested OK in Seamonkey 2.22
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: