Bad character encoding of inline HTML forwarded multi-part messages

RESOLVED WORKSFORME

Status

--
major
RESOLVED WORKSFORME
9 years ago
a month ago

People

(Reporter: earlpiggot, Unassigned)

Tracking

1.9.1 Branch
x86
Windows XP

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

9 years ago
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
(Reporter)

Comment 2

9 years ago
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.

Comment 3

9 years ago
Please attach a sample message (save as .eml)

Comment 4

8 years ago
using TB 3.0.6 (had this problem since 3.0.X)
Same problem here but with Hebrew.
I'll try to attach .eml

Comment 5

8 years ago
Created attachment 458971 [details]
Original mail message

This is the original mail message with Hebrew text.

Comment 6

8 years ago
Created attachment 458972 [details]
Forwarded message

this is the forwarded message.
Note that the Hebrew test in now garbled.

Comment 7

8 years ago
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.

Comment 9

2 years ago
I cannot reproduce with Thunderbird 38.7.1
Can you still reproduce it with the latest version?
Flags: needinfo?(zipo13)
Flags: needinfo?(earlpiggot)

Comment 10

2 years ago
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)

Comment 11

a month ago
WFM per comment 10
Status: UNCONFIRMED → RESOLVED
Last Resolved: a month ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.