User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20100101 Firefox/11.0 Build ID: 20120312181643 Steps to reproduce: On a "western" Windows system using Thunderbird 11, I composed a message and changed the encoding to UTF-8. I didn't send that message but saved it in the Drafts folder. Later, I double-clicked that message to continue editing Actual results: The message's contents were interpreted as ISO-8859-1. That was the setting shown in Options > Character Encoding, and non-ASCII characters were showing the often-found UTF-8 "artifacts" (e.g. ü became Ã¼). This did not happen with the following workaround: right-click the message in the drafts folder and choose "Open message in new window" and click the "Edit" button. Strangely, when testing a bit further, I found that at times the encoding was in fact read properly as the message was double-clicked. I observed three times that using "open in new tab" on the message would trigger that change. Don't confuse this with the workaround I described earlier: whether I opened in a new tab or a new window, clicking the "Edit" button in that display tab or window would always give me an edit window with the right encoding. But after "open in new tab", I could close the tab and simply double-click the message in Drafts and also get the correct encoding. But then, after a period of inactivity (maybe actions like editing the draft and saving it again, or composing another message using the same drafts folder had an influence, I don't know), the issue reappeared. Copying the message from the Drafts folder of the IMAP account to the Drafts folder under Local Folders showed the same behaviour for the copy. The Content-Type header was of course set (text/plain; charset=UTF-8; format=flowed), I went through TB's regular composition process. Expected results: TB should read the encoding from the message as soon as it's double-clicked (i.e. the "Edit as new" function is executed), reliably.
(In reply to Sebastian Lisken from comment #0) As far as I know, the "Default Character Encoding" setting of the folder having the draft has an influence on the saved message.
Same as or similar to bug 597369 or bug 701694? If Edit by double click, I could see problem of bug 701694 only with message pane hidden. With message pane shown, "Edit As New via context menu" is still needed to see bug 597369.
I've just tried some more, and it's true that activating the preview pane seems to prevent the problem. So maybe this is a duplicate of bug #701694, but for now I'll add my observations here. In reponse to comment #1 I can say that I changed the encoding of my message explicitly before saving. My impression now is that the encoding chosen for the edit window when I double-click my saved message is neither the encoding that could be read from the message (which is what it should be) nor, probably, the default encoding of the folder. It seems to be cached somehow. Have a look at my latest experiments - here's what I did: - Had about four messages in my draft folder, some composed as ISO-8850-1, some as UTF-8 - Opened the preview pane to ensure that the encoding was right, and doubled-clicked an UTF-8 message; it was edited in UTF-8 (and read correctly) - Closed the preview pane, and double-clicked all the messages. They were all edited as UTF-8, and those messages that were saved as ISO-8859-1 were converted correclty. - Opened the preview pane again, and double-clicked one of the ISO-8859-1 messages. The new edit window was using ISO-8859-1. - Closed the preview pane, and double-clicked all messages. All the edit windows were now in ISO-8859-1, and the UTF-8 messages were not converted correctly. It seems that TB remembers or caches an encoding that it "wants to use" if a message from Drafts is double-clicked, and that this cached encoding can be changed by activating the preview pane and double-clicking a message whose encoding is different to the currently preferred one. Or it can be changed, as I could also see, by opening a message whose encoding was different in a tab, and displaying that tab. That last bit is important. Just opening in a tab doesn't focus that tab, at least as long as mail.tabs.loadInBackground has the default value of false. If the tab is closed again without bringing it to the foreground, TB doesn't change the encoding it wants to use. It's interesting that a conversion took place one-way (open an ISO-8859-1 message when the encoding TB seemed to remember was UTF-8), but no conversion took place the other way (open a UTF-8 message when the encoding TB "wanted" was ISO-8859-1). I wonder why TB didn't check for the need to re-encode when it wants to use ISO-8859-1 in the edit window. Could it be because ISO-8859-1 was the folder's default encoding, i wondered? It seems not - because when I changed my IMAP folder's default encoding to UTF-8 and tried it again, it still worked the same way round. When TB "wanted to use" UTF-8, a double-clicked ISO-8859-1 message was converted in the edit window. When TB "wanted to use" ISO-8859-1, a double-clicked UTF-8 message was not converted.
(In reply to Sebastian Lisken from comment #3) > I've just tried some more, and it's true that activating the preview pane > seems to prevent the problem. So maybe this is a duplicate of bug #701694, (snip) Duping per response. Re-open if duping is wrong, with stating detail of differences from that bug, with data for problem analysis, please.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 701694
You need to log in before you can comment on or make changes to this bug.