Closed
Bug 397404
Opened 18 years ago
Closed 13 years ago
German umlauts (and maybe further special characters > ASCII 127) are destroyed after switching on the mail preview window
Categories
(SeaMonkey :: MailNews: Message Display, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 1287336
People
(Reporter: robert.boeck, Unassigned)
Details
(Whiteboard: [2012 Fall Equinox])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.4.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.4.0
If I switch on the preview window, the german umlauts (mutated vowels) are not shown in the preview window, instead of them there are two cryptical special characters shown for each umlaut. After selecting an other mail, the umlauts are shown correctly in the preview window.
Reproducible: Always
Steps to Reproduce:
1. Open the e-mail window with the preview window switched off.
2. Select a mail that contains german umlauts (or maybe other charachters > ASCII 127)
3. Open the e-mail preview window
Actual Results:
The german umlauts are shown as two cryptical special charaters.
Expected Results:
The german umlauts should be shown as german umlauts.
Comment 1•18 years ago
|
||
(Q1) What is set as "Default Character Encoding" for mail display
(Q2) What is set in charset parameter in Content-Type: header of mail source
(Q3) What is set in View/Character Encoding of main window
a. Auto-detect
b. Currently used character encoding indicated by a dot
(detected or based on default, or based on charset, or modified manually)
(Q4) What is set in View/Character Encoding of the opened mail display window
a. Auto-detect
b. Currently used character encoding
Check View/Character Encoding at each mail display step.
Reporter | ||
Comment 2•18 years ago
|
||
(Q1) Western (ISO-8859-1)
(Q2) Content-Type: text/plain; charset=ISO-8859-1; format=flowed
(Q3) a. (Off)
b. Western (ISO-8859-1)
(Q4) a. (Off)
b. Western (ISO-8859-1)
Reporter | ||
Comment 3•18 years ago
|
||
Reporter | ||
Comment 4•18 years ago
|
||
Comment 5•18 years ago
|
||
(Q5) Is Subject: header of the mail encoded? If yes, in what encoding?
(Q6) Will Auto-Detect=On(ISO-8859-1) resolve problem?
Reporter | ||
Comment 6•18 years ago
|
||
(Q5) no
(Q6) there is no ISO-8859-1 option under Auto-Detect
Comment 7•18 years ago
|
||
(In reply to comment #6)
> there is no ISO-8859-1 option under Auto-Detect
Sorry. Try Auto-Detect=Universal, please.
By the way, I experienced funny phenomenon with Semonkey 1.1.4.
(1) Auto-detect=Japanese, ISO-2022-JP mail, Preview pane display is OK
(2) Change Auto-detect to Universal
Peview pane display becomes whole mail data display as text
("From -..." line, header lines, body text)
(3) Click other mail -> OK, click mail of (1) again -> OK
Different problem, but it seems to be another character encoding related problem.
Reporter | ||
Comment 8•18 years ago
|
||
> Sorry. Try Auto-Detect=Universal, please.
Doesn't solve the problem neither. Same problem as you experienced. The first mail in the preview window is shown as source of the mail without line breaks. Clicking an other mail solves the problem. But clicking an other mail solves the umlaut problem, too.
Comment 9•18 years ago
|
||
Re-produced with Seamonkey 1.1.4(MS Win-XP SP2), using ISO-2022-JP mail.
(0) View/Character Encoding/Auto-Detect=Off(Layout=Classic View,Theme=Modern)
(1) Switch off mail preview pane
(2) Click other mail folder (close the mail folder)
(3) Click the mail folder again (open the mail folder)
(4) Click a mail in a thread pane
(5) Open mail preview pane => garbage was displayed
(6) Switch off mail preview pane again
(7) Open mail preview pane again => normally displayed
It seems that just after mail folder open only, and I couldn't reproduce problem when Auto-Detect=Japanese.
Comment 10•18 years ago
|
||
This seems to be old problem.
See Bug 315957 Comment #0. (Bug 315957 is already sufficiently messy)
Updated•18 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 11•17 years ago
|
||
Can you reproduce with SeaMonkey v1.1.9 ?
Can you reproduce with SeaMonkey v2.0a1pre ?
Version: unspecified → SeaMonkey 1.1 Branch
Reporter | ||
Comment 12•17 years ago
|
||
I can reproduce it with SeaMonkey/1.1.9
Comment 13•13 years ago
|
||
When you see the bug, does it disappear when you hit F5? Or if you open a Message Compose window by clicking Reply? If it does, then this is probably a duplicate of bug 315957
Whiteboard: [2012 Fall Equinox]
Updated•13 years ago
|
Flags: needinfo?(robert.boeck)
Reporter | ||
Comment 14•13 years ago
|
||
(In reply to Tony Mechelynck [:tonymec] from comment #13)
> When you see the bug, does it disappear when you hit F5?
Yes.
> Or if you open a
> Message Compose window by clicking Reply?
Yes.
I know what the garbage is. These are characters in UTF-8 multi-byte encoding where each single byte is displayed in ISO-8859-1 encoding.
Another variant of maybe the same bug:
1. Switch to the Sent folder.
2. Select a message containing german umlauts, but don't open it.
3. Press Ctrl-E (Edit Message As New).
Workaround:
2.1. Open the message before pressing Crtl-E and there is no problem.
Verified with the most recent SeaMonkey/2.13.2.
Flags: needinfo?(robert.boeck)
Comment 15•13 years ago
|
||
OK. This seems to be a duplicate of bug 315957 which has a known regression range (last good: 2006-04-08, first bad: 2006-04-09).
FWIW, I see the same bug (but not systematically, see bug 315957 comment #31 and #32) and if ever that bug gets FIXED, I'll check if I still see it on a trunk build (of whatever version "trunk" will be by then — at the moment it's 2.16a1). Since you're using "release" builds, the fix (if there ever is one) may reach you a little later than it does me (between six weeks and six months depending, among others, on how important it will by then be felt to propagate the fix to "earlier" code branches).
Let's hope that someday it does get fixed.
If ever we still see this bug on executables containing the (eventual) fix for bug 315957, this bug may have to be REOPENED.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•