Non-Latin characters in first previewed message (after mail startup) are not readable



18 years ago
11 years ago


(Reporter: bugzilla3, Assigned: nhottanscp)



Windows 95

Firefox Tracking Flags

(Not tracked)



(3 attachments)



18 years ago
Steps to reproduce:
1. Close Mozilla (everything), shutdown "turbo" resident part (if active).
2. Start Mail client (be sure not to invoke browser first) 
3. On 3-pane view, preview a message with non latin characters.
4. Switch to another message, switch to the original message again.

Expected results:
After step 3, message is readable. Same for step 4.

Actual Results:
After step 3, non latin characters are unreadable, even if there is corect mime
information. After step 4, results are as expected (until you shutdown Moz and

The bug appeared on build 2001101003, so some checkin of 9 Oct 2001 (trunk) is
responsible. I suspect bug 68045. One more evidence for bug 68045 are the
a. if I delete  xul.mfl and restart mail, bug disappears but re-appears on
subsequent startups
b. normal operation if I disable fastload with
"user_pref("nglayout.debug.disable_xul_fastload", false);"

Conditions: build 2001101003 or newer, Win95/98, default charset is ISO-8859-7,
no charset override.

Comment 1

18 years ago
additional note: to reproduce the bug, the message which has non latin
characters in its body must be the first to be displayed in preview pane. If a
message without latin characters is by default the first to be displayed after
Mail startup, you will fail to reproduce.

Comment 4

18 years ago
I can't reproduce with 2001-10-29-11-trunk build by following the same steps.
Dimitrios, after step3, is that all the non-latin1 mails are not readable or
just the attached mail has problem?

Comment 5

18 years ago
Any mail with non-latin characters is unreadable, if it is the first to be
previewed, after Messenger startup.
After further investigation, I narrowed my case a bit further: a few days ago I
needed to erase xul.mfl, in order to resolve visual problems from one trunk
build to another. I think this deletion was the start of the problem (tonight I
had no problem until I erased xul.mfl again). So, in order to reproduce, please
check if you have fastload enabled, delete your xul.mfl file and restart
Messenger two times before testing.

Comment 6

18 years ago
Hmmm, I still can't see the problem. I deleted xul.mfl, restarted mail, 
 and viewed the attached mail as the 1st mail after I logged in. The mail was
displayed alright. Dimitrios, are you using a IMAP or POP? I don't have problem
with either of them. Marina, could you also try? Thanks.

Comment 7

18 years ago
i tried it with 2001-10-30 build and i wasn't able to reproduce it though in one
instance the first message in my non-ascii folder was displaying as arabic being
cyrillic koi8-r (wierd) . I deleted xul.mfl, i restarted mail( how critical it
it to restart it twice??)

Comment 8

18 years ago
I use pop, modern theme, alt layout, no charset override. None of the above
affect my bug (not sure for pop, since there's no imap account available).
Second mail restart is critical: after deleting xul.mfl, first mail start has no

Today I used the typical last resort: deleted \program files\,
\win95\Mozilla, \win95\moz*.*. Then I installed 2001103003. After setting up my
email account and closing Mozilla, I copied my old Mail folder into the new
\win95\Mozilla\xxx\Mail directory. After disabling "When Mail launches, show the
Start Page in message area", subsequent restarts always reproduce the problem.
Maybe this option is what prevents you from reproducing the bug? You must not
allow any other  message to be previewed first (like the default Start Page).

Comment 9

18 years ago

Comment 10

18 years ago
Dimitrious, i tried all your steps with POP account and i am still with no luck
to reproduce it.

Comment 11

18 years ago
I was able to reproduce this with 10/30 trunk build.
Below is the steps I used.
1. Launch Mail, Go to Edit | Preferences | Mail & Newsgroups, uncheck the
checkbox of "When Mail launches, show the Start Page in the message area".
2. Exit application, delete xul.mfl in the profile folder.
3. Launch Mail directly from application folder (which is located in the Start
Menu folder), don't launch browser first.
4. Login to the mail account (It doesn't matter the account is IMAP or POP,
since I saw this using an IMAP while Dimitrios saw this with a POP acccount),
select an non-ascii mail as the first mail to view. It's displayed okay at this
5. Exit Mail, restart it again.
6. Select an non-ascii mail as the first mail to view, for example, a normail
Japanese mail with MIME charset info or the testing mail attached to this
report, the mail body is displayed garble! Then
select another one, it's displayed alright, then go back the first one you
viewed as garbled, it's displayed okay.

So with these conditions (Disable the checkbox of Mail Start page, delete
xul.mfl, restart Mail directly twice), then if the first mail you view is an
non-ASCII mail, it won't be displayed correctly, and the display problem only
occurs to the first mail. An interesting bug.
Ever confirmed: true


18 years ago
Keywords: intl

Comment 12

18 years ago
i see now what step i skipped: luanch mail twice! on the second luanch with all
other steps the first non-ascii (utf -8 ja message) was not displaying its body
at all, it was blank, but when i went back to it the display was fine... very
wierd but not that critical.


18 years ago
Target Milestone: --- → Future


16 years ago
Summary: Non latin characters in first previewed message (after mail startup) are not readable → Non-Latin characters in first previewed message (after mail startup) are not readable

Comment 13

16 years ago
Is this bug valid now?

Comment 14

16 years ago
Dimitrios, are you still seeing this bug?

Comment 15

16 years ago
No, I'm not seeing this anymore and I should have closed it a long time ago. Sorry.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME

Comment 16

16 years ago
thanks! verifying.
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.