Open Bug 367240 Opened 18 years ago Updated 11 years ago

View/Character Encoding overrides the encodings specified for attachments shown inline (SeaMonkey can't display mail/.eml as expected if mail has different charset for mail body and attachment)

Categories

(SeaMonkey :: MailNews: Message Display, defect)

Product:
SeaMonkey
Component:
MailNews: Message Display
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

People

(Reporter: mmokrejs, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: intl)

Attachments

(4 files)

testcase.eml
6.86 KB, message/rfc822
Details
correctly_rendered_html_part_in_cp1250.jpg
46.52 KB, image/jpeg
Details
correctly_rendered_text_part_in_iso_8859-2.jpg
16.84 KB, image/jpeg
Details
misrendered_except_Subject_in_UTF8.jpg
103.40 KB, image/jpeg
Details 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070104 SeaMonkey/1.0.7
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.9) Gecko/20070104 SeaMonkey/1.0.7

I have received an email which has no encoding specified in email header and has an html attachment, which does contain 

<meta http-equiv="Content-Type" content="text/html;  charset=windows-1250">

So, the attachment is shown correctly when opened in a new seamonkey browser window. But, when I have enabled View/Display Attachments Inline, the attachment is rendered like to be in my default encoding, which is UTF8. So, the characters are screwed in display.

I wonder whether there is an additional bug that even when the email would have in this particular case contain in the email header defined encoding (iso-8859-2) whether the Inline attachment would be rendered in UTF8 or in the 8859-2 encoding. In both cases it would be wrong.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
I can confirm the problem in Thunderbird (Version 1.5.0.10, Ubuntu).
Are many of mail bodies and HTML attachments written in UTF-8? Isn't it rare?

I think currently available practical workaround in your case is :
(At least partially readable in many cases, I think)
  1. Set default character encoding of mail display to one of next;
     a. Charset of mails you need to read every day (I think it's not UTF-8)
     b. Similar encodings to CP932. windows-1252, iso-8859-1, iso-8859-2, ...
  2. Set View/"Character Encoding"/"Auto Detect" appropriately
     (to most convenient one for you)

And per-folder "Default Character Encoding" is already available by SeaMonkey 1.1 (thru property of a mail folder).
This can make above workaround much practical.
I have View/"Character Encoding"/"Auto Detect set to Off, by even turning it on and to "Universal" (which is I believe UTF8) I see the message still broken.

I have set folder character encodings, but would you believe I have set it to UTF8? ;-))

I really mean thunderbird should render inlined attachments in the encoding specified in them:

Subject: =?iso-8859-2?Q?Objedn=E1vka_byla_p=F8ijata_pod_=E8=EDslem_:_2007015591_.?=

This is a multi-part message in MIME format.

------=_NextPart_000_0001_01C73A3F.C8469CD0
Content-Type: text/plain
Content-Transfer-Encoding: 8bit

...

------=_NextPart_000_0001_01C73A3F.C8469CD0
Content-Type: text/html;
	name="objednavka.htm"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="objednavka.htm"

<!doctype html public "-//W3C//DTD HTML 4.0 =
Transitional//EN"><html><head><title>Objedn=E1vka</title><meta =
http-equiv=3D"Content-Type" content=3D"text/html;  =
charset=3Dwindows-1250"><meta name=3D"description" content><meta =
name=3D"keywords" content><meta http-equiv=3D"Content-language" =
content=3D"cs"></head>
<body>
blah
</body>
/html>
------=_NextPart_000_0001_01C73A3F.C8469CD0--
(In reply to comment #3)
> I really mean thunderbird should render inlined attachments in the encoding
> specified in them:

My suggestion is simply a *PRACTICAL* circumvention.
I agree with you on this bug's issue, and I'm slightly aggressive on multi-encoding than you, although it will be still Greek for me even if correctly displayed :-)
 1-a. From: header      : encoded in ISO-2022-CN
 1-b. Subject: header   : encoded in EUC-KR
 1-c. Mail body         : charset=ISO-IR-111
 1-d. HTML attachments  : 1=UTF-16, 2=MacArabic, 3=MacGreek, ... 
 1-e. An HTML attachment: body=UTF-32, iframe-1=MacGreek, ...
 ( Note: This bug is for 1-c/1-d(and 1-e?) only.                 )
 (       1-a/1-b/1-c is different issue and is already reported. )

Can you attach test case which is useful in problem re-creation test and fix verification test?

(Off Topic)
By the way, I'm probably expecting perfect/ideal solution for next,
 2-a. From: header    : Raw data of ISO-2022-JP, no-encoding,
 2-b. Subject header  : Raw data of Shift_JIS, no encoding,
 2-c. Mail body       : no charset but data is EUC-JP,
 2-d. HTML attachment : data=UTF-32 Little Endian, charset=UTF-16 Big Endian,
although "spam filer" was/is/will be sufficient solution for me ;-)
Attached file testcase.eml — 
First body part is in iso-8859-2, while the html file is in quoted-printable windows cp1250.
(In reply to comment #5)
> testcase.eml
Thanks for test case and images of expected/correct display. 
Could you attach two more jpeg's, please, to see problem without double check.
1.Mail rendered by UTF-8, 2.Mail rendered by iso-8859-x(one fits to your locale)
My default encoding is UTF8 (in seamoenkey) and also defined by environment LOCALE. Gentoo linux really instructs users to use UTF8 as default locale.
CC-ing to Jshin.
Does latest Gecko handle multi-encoding in a page well?
If not, is it easy to develop? 

Adding "different charset" in summary for ease of search.
Summary: View/Character Encoding overrides the encodings specified for attachments shown inline → View/Character Encoding overrides the encodings specified for attachments shown inline (different charset for mail body and attachment)
In your "testcase", the "Content-Type" headers include no "charset" attribute, thus leaving it to SeaMonkey to guess it.

Using
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041301 SeaMonkey/2.0a1pre

Clicling the attachment link opens the source in Sm Browser, I have to change it manually to ISO-8859-2 to see the text part etc.

Saving it to disk then renaming it with a .eml extension allows it to open in the Mailer. The HTML is OK but even after changing View -> Character Encoding the top part's accented characters look like gibberish.
Assignee: mail → smontagu
Component: MailNews: Main Mail Window → MailNews: Internationalization
OS: Linux → All
Product: Mozilla Application Suite → Core
QA Contact: mailnews.i18n
Hardware: PC → All
Product: Core → MailNews Core
Confirming by screenshot attached to Comment #9. (I forgot to set CONFIRMED)

(In reply to comment #5)
> testcase.eml

Quick check result with attachment saved in local ".eml" file.

(1) Shredder setting : View/Display Attachments Inline=Enabled
    (1-1) Opened by Fx 3.5 => passed to Shredder
    (1-2) Open saved message of Shredder
    Both text/plain part and text/html part is displayed as expected.
    (text/html part is didplayed using IFRAME like XUL element)
    => Already WORKSFORME in Shredder.

(2) Seamonkey trunk(Gecko 1.9.1) 2009/7/20 build.
    View/Display Attachments Inline=Enabled.
    (2-1) Open ".eml" file => Displayed in Browser's Tab.
          One of two parts is garbled both with Auto Detect=(Off) & Universal.
 
Martin Mokrejs(bug opener):

Can you reproduce problem with Seamonkey trunk(1.9.1), with mail in mail folder?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Still problem in

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090801 SeaMonkey/2.0b2pre

If I force correct encoding of the "body" to iso-8859-2 the attachment in HTML is screwed.
Playing with Autodetect does not really help, nor changing default encoding over the whole mailbox folder.
Changing to Product=SeaMonkey, because Shredder doesn't have problem any more.
Please correct it if wrong.
Assignee: smontagu → nobody
Component: Internationalization → MailNews: Message Display
Product: MailNews Core → SeaMonkey
QA Contact: i18n → message-display
Summary: View/Character Encoding overrides the encodings specified for attachments shown inline (different charset for mail body and attachment) → View/Character Encoding overrides the encodings specified for attachments shown inline (SeaMonkey can't display .eml as expected if mail has different charset for mail body and attachment)
Comment on attachment 262941 [details]
testcase.eml

Changing MIME Type of the attachment to message/rfc822 to see display result by browser.
Note: B.M.O doesn't set charset=UTF-8 automatically for message/rfc822, so result by auto-detect can be checked.
Attachment #262941 - Attachment mime type: text/plain → message/rfc822
Summary: View/Character Encoding overrides the encodings specified for attachments shown inline (SeaMonkey can't display .eml as expected if mail has different charset for mail body and attachment) → View/Character Encoding overrides the encodings specified for attachments shown inline (SeaMonkey can't display mail/.eml as expected if mail has different charset for mail body and attachment)
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: