Closed Bug 507888 Opened 15 years ago Closed 6 years ago

Bad character encoding of inline HTML forwarded multi-part messages

Categories

(MailNews Core :: MIME, defect)

1.9.1 Branch
x86
Windows XP
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: earlpiggot, Unassigned)

References

()

Details

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090801 Minefield/3.6a1pre (like Firefox 3.5.1) (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1) Gecko/20090715 Thunderbird/3.0b3 ID:20090715140311

I want to Shift-Forward (plain text and inline forwarding are my respective preferences) a MIME message (which I preview as HTML) with the following structure:


[......]
MIME-Version: 1.0
Content-Type: multipart/related;
        boundary="----=_NextPart_000_0000_01C6527E.AE8904D0"

This is a multi-part message in MIME format.

------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: multipart/alternative;
        boundary="----=_NextPart_001_0001_01C6527E.AE8904D0"

------=_NextPart_001_0001_01C6527E.AE8904D0
Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit

[The message in plain text with Greek and Latin characters]
                       
------=_NextPart_001_0001_01C6527E.AE8904D0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit

[The HTML message with a reported MUA "Microsoft DHTML Editing Control". The content text is primarily in Greek again. This is designated with the lang=EL attribute in P, DIV and SPAN elements]

------=_NextPart_001_0001_01C6527E.AE8904D0--

------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: image/jpeg;
        name="someimage1.jpg"
Content-Transfer-Encoding: base64
Content-ID: <015522113@30072009-2880>

[some image in base64]

------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: image/jpeg;
        name="someimage2.jpg"
Content-Transfer-Encoding: base64
Content-ID: <015522113@30072009-2887>

[and another image]

------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: image/jpeg;
        name="someimage3.jpg"
Content-Transfer-Encoding: base64
Content-ID: <015522113@30072009-288E>

[and another]

------=_NextPart_000_0000_01C6527E.AE8904D0
Content-Type: image/jpeg;
        name="someimage4.jpg"
Content-Transfer-Encoding: base64
Content-ID: <015522113@30072009-2895>

[one more image]

------=_NextPart_000_0000_01C6527E.AE8904D0--


The message is forwarded with the same original content both in HTML and plain text and attachment parts, except that all Greek texts becomes unreadable being encoded and showing up unreadable, like
         Ξ�ΞΏΟ�Ο�ΞΉΞΏΟ�β�¦Ξ� ΞΊΞ±Ο�άβαΟ�Ξ...

And this happens both in plain text and HTML sections...


Reproducible: Always

Steps to Reproduce:
1. Receive a multi-part message, preferably prepared in "Microsoft DHTML Editing Control". The headers should read

MIME-Version: 1.0
Content-Type: multipart/related;

The plain text part should have the headers:

Content-Type: text/plain;
charset="utf-8"
Content-Transfer-Encoding: 8bit

and its content should be a mix of Greek and latin characters

The HTML part should have similar headers:

Content-Type: text/html;
 charset="utf-8"
Content-Transfer-Encoding: 8bit

and its content should be primarily in Greek again. Furthermore, this is designated with the lang=EL attribute in P, DIV and SPAN elements.

2. Forward it inline as HTML
Actual Results:  
Greek characters text of the forwarded message become unreadable, no matter what encoding you try in viewing, BOTH in plain text and HTML view:

�α�αβά�Ρι�: 6 και 7 ��γο���ο�

�ο��ιο��� κα�άβα�η ξΡκινάΡι μ�νο μΡ �ι� �κιέ� ��ν δέν���ν, �ην α��λ��η η���ία, �ο ά�αν�ο νΡ����

Φ�άνον�α� ��ον �λ�Ρι���ο �κο�άδι δίνΡι �ην θέ�η �ο� ��ο ��

Expected Results:  
The forwarded message should read exactly as the original and should display more or less like it.


My related preferences are plain text for new messages I write, UTF-8 silently imposed when necessary, send both in plain and HTML when needed, view in ISO-8859-7 when encoding information is absent, and finally use ISO-8859-7 in composition whenever possible. I tried other settings too to see if something that I miss is assumed, but no luck.
Earl did this use to work in previous versions of Thunderbird ?
Component: General → MIME
Product: Thunderbird → MailNews Core
QA Contact: general → mime
Version: unspecified → 1.9.1 Branch
The option to toggle between HTML and plain text Forward with the Shift key was not implemented in previous versions. I always used Forward as attachment then, using third party extensions (either Forward or FortwardAs), so, "I don't know" is the answer to your question.
Please attach a sample message (save as .eml)
using TB 3.0.6 (had this problem since 3.0.X)
Same problem here but with Hebrew.
I'll try to attach .eml
Attached file Original mail message
This is the original mail message with Hebrew text.
Attached file Forwarded message
this is the forwarded message.
Note that the Hebrew test in now garbled.
related to bug 196180
Removing myslef on all the bugs I'm cced on. Please NI me if you need something on MailNews Core bugs from me.
I cannot reproduce with Thunderbird 38.7.1
Can you still reproduce it with the latest version?
Flags: needinfo?(zipo13)
Flags: needinfo?(earlpiggot)
Hi,
Yes I can confirm that this bug does not happen any more.
Tested just now on TB 45.
This can be closed.
Itamar
Flags: needinfo?(zipo13)
Flags: needinfo?(earlpiggot)
WFM per comment 10
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: