368812 - Prefer charset specified within HTML attached file over the encoding used to render the email itself

Status: RESOLVED WORKSFORME

(SeaMonkey :: MailNews: Message Display, defect)

Description

[Martin Mokrejs]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 SeaMonkey/1.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070130 SeaMonkey/1.1

Although I do agree the tescase which I will attach is partly screwed in terms that no encoding is specified in the email header, at the the HTML attachment should be correctly rendered as it does contain encoding type. That can be even confirmed by double-cliking the attachment and letting it opened by web browser. But, when attachment is displayed inline, it is not rendered correctly:

1. it seems it is rendered in UTF8 in my case, which is my system-wide encoding on this linux host
2. it seems it is rendered in UTF8 although the default encoding for the message folder is set to iso-8859-2 (which luckily is the encoding used for the first, textual attachment in this testcase)

So it seems the encoding specified for the folder is not applied for in-line attachments, somehow, which is probably wrong as well if they do not specify their own encoding.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Martin Mokrejs]

Attachment: testcase2.eml.gz

Although not specified, the text/plain part is in iso-8859-2.

Comment 2

[Tony Mechelynck [:tonymec]]

WFM using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008032201 SeaMonkey/2.0a1pre

The HTML part is correctly displayed with Czech diacritics;

The text/plain part, which has no "charset" attribute in its (attachment-level) Content-Type header, looks wrong (displayed in iso-8859-1 on my system).

The testcase is against the standards anyway, its Content-Type headers should have a charset attribute.

Resolving WORKSFORME.