Reusing a message from sent messages mixes up character encoding (ISO-8859-1 vs. UTF-8)

RESOLVED DUPLICATE of bug 597369

Status

Thunderbird
Message Compose Window
--
minor
RESOLVED DUPLICATE of bug 597369
7 years ago
3 years ago

People

(Reporter: Andreas Kern, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.16) Gecko/20110322 Fedora/3.6.16-1.fc14
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; de-DE; rv:1.9.2.15) Gecko/20110305 Lightning/1.0b3pre Thunderbird

When re-using a message from the sent folder, character encoding in the composing window depends not on the message selected but most likely on the messages viewed before.

Reproducible: Always

Steps to Reproduce:
1.Change to inbox, select a message with UTF-8 encoding
2.Change to "sent" folder
3.Only right click on a message in ISO-8859-1 and select "re-compose"(in German:'Als neu bearbeiten') Do _not_ select the message with a left click!
4.

Actual Results:  
The composing window displays the message content in UTF-8 encoding, instead of ISO-8859-1, especially umlaut characters are not displayed correctly

Expected Results:  
Right behaviour should be to use the recent message encoding, not the last one of the reading window.

Comment 1

5 years ago
Looks like a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=597369

Comment 2

3 years ago
I tried this in TB 45 (Earlybird):

1) Went to my inbox, selected a message which is UTF-8 encoded.
   I verified: View > Text Encoding, showed "Unicode".
2) Clicked onto the "Sent" folder.
3) Immediately right clicked onto a message that was written in windows-1252 (ANSI),
   and selected "Edit As New Message".

The compose window does show Umlaute and other characters OK (äöüßñ) correctly, but a quote (’), ANSI 0x92 or U+2019, appears as a little box with displaying 00/92.

This bug has morphed a bit since TB doesn't seem to support ISO-8859-1 any more. Windows-1252 identical to ISO-8859-1, for the code points 128-159 (0x80-0x9F).
Source: http://www.i18nqa.com/debug/table-iso8859-1-vs-windows-1252.html

So the reported problem still exists, however the Umlaute look OK in the "new" message.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 597369
You need to log in before you can comment on or make changes to this bug.