German umlauts (and maybe further special characters > ASCII 127) are destroyed after switching on the mail preview window

RESOLVED DUPLICATE of bug 1287336

Status

--
minor
RESOLVED DUPLICATE of bug 1287336
11 years ago
2 months ago

People

(Reporter: robert.boeck, Unassigned)

Tracking

SeaMonkey 1.1 Branch
x86
Windows 2000

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [2012 Fall Equinox])

Attachments

(2 attachments)

(Reporter)

Description

11 years ago
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.
(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

11 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

11 years ago
Created attachment 282256 [details]
example of wrong umlaut display
(Reporter)

Comment 4

11 years ago
Created attachment 282258 [details]
example of correct umlaut display
(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

11 years ago
(Q5) no
(Q6) there is no ISO-8859-1 option under Auto-Detect
(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

11 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.

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.
This seems to be old problem.
See Bug 315957 Comment #0. (Bug 315957 is already sufficiently messy)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you reproduce with SeaMonkey v1.1.9 ?
Can you reproduce with SeaMonkey v2.0a1pre ?
Version: unspecified → SeaMonkey 1.1 Branch
(Reporter)

Comment 12

11 years ago
I can reproduce it with SeaMonkey/1.1.9
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]
(Reporter)

Comment 14

6 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)
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
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 315957

Updated

2 months ago
Duplicate of bug: 1287336
You need to log in before you can comment on or make changes to this bug.