1035523 - "Edit as new" Changes Message Body from Plain Text to Chinese

Status: RESOLVED WORKSFORME

(Thunderbird :: Message Compose Window, defect)

Description

[David E. Ross]

Attachment: Screen shot of the original message.

Windows 7 (x64)
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0

I have a message with 20 plain-text files attached.  I needed to resend it to a different E-mail address.  All my messages -- new, replies, and forwards -- are plain text.  

When I selected "Edit as new" for the original message, the body appeared to all be Chinese characters.  I had to go back to the original message, copy the body, and paste it into the new message.  

This appears to be related either to the number of attachments or the total size of the attachments.  I do not see this when working with an original message that has no attachments or even three very short attachments.  

Note that the attached screen shots were taken while running Thunderbird in Safe Mode.

Comment 1

[David E. Ross]

Attachment: Screen shot of "Edit as new" compose window from the original message (prior attachment).

Comment 2

[Wayne Mery (:wsmwk)]

this is incomplete without a testcase

Comment 3

[David E. Ross]

Attachment: The message for which this bug report was submitted

The attached file "test temp" was created by copying the subject message into a new message folder with that name.  It is the only message in that folder.  

Viewing the file via Wordpad in Windows 7, I see it is indeed the message.  Opening it in Thunderbird, I also see the message.  However, selecting the message and then right-clicking and selecting Edit As New Message, I again see what appear to be Chinese characters.  

The SHA1 hash for this file is 2237be0d17bf88848f6fd9d6c93ba2aa91cc1c12.  I hope this provides sufficient test material.

Comment 4

[Ronald Killmer]

From within attachment 3 [details] [diff] [review] I copied this from the first b46 encoded block:
Content-Type: text/plain; charset=UTF-16LE;
 name="doPDF_8_20140627150443_0_OemPackagex64.8.0.907.log"

That is a Asian language encoding, not western UTF-8.

Comment 5

[ISHIKAWA, Chiaki]

Hi,

The question would be then why "UTF-16LE" was picked up.

How did the original poster inserted the attachment?

And then the question would be how the charset was recognized automagically ???

I have had a few issues of mangled character set recognition when I try to "forward" a message with
a few attachment of plain text files, and got the main body of the text mangled.
That bug is being worked on:
Bug 715823 - Forward message, wrong encoding (if different charset is used in part under multipart/mixed, charset of last part is used in forward/edit as new, without converting data to the charset)
 
I think the root cause of the bug 715823 may have something in common with this bugzilla.

Comment 6

[:aceman]

Jorg, may some of your charset work help here?

Comment 7

[Jorg K (CEST = GMT+2)]

(In reply to :aceman from comment #6)
> Jorg, may some of your charset work help here?
I can't reproduce the problem. I imported the message into last week's Earlybird (TB 46) and it works just fine. When editing the message as new I see this in the titlebar:
Write: Cannot Uninstall doPDF 8.0.907 - Unicode (UTF-16LE).

This seems to have been picked up from one of the attachments, some of which have
Content-Type: text/plain; charset=UTF-16LE;

I think bug 715823 may have something to do with it, but also it may already be fixed by bug 1239658 or bug 597369.

Note that reply to the message uses UTF-16LE whereas forward uses windows-1252, which is also a charset used in the message.

This was reported on TB 24, so right now, I can't do anything here. In fact, I'd close this as "WORKSFORME".

Can someone try this on the latest trunk and then close the bug.

Comment 8

[Wayne Mery (:wsmwk)]

per comment 7