245552 - default character encoding option for outgoing mail is unusable

Status: RESOLVED FIXED

(Thunderbird :: Preferences, defect)

Description

[Dimitrios]

With the branch zip build (version 0.6+ 20040603), I am not able to change the
default character encoding for outgoing mails. Steps to reproduce:
In Tools->Options->Fonts the "Outgpoing mail" option cannot be viewed/changed. 
See attached screenshot. Tested with new profile.

Comment 1

[Dimitrios]

Forgot to mention that the associated select box has smaller than normal
vertical size.

Comment 2

[Dimitrios]

Attachment: screenshot

Comment 3

[Scott MacGregor]

many folks who see this turns out they weren't doing clean installs. Please make
sure you are doing a clean install.

Comment 4

[Dimitrios]

Scott, I repeated the procedure although I was sure I made a clean install
before filing the bug. Your suggestion has much sense (from the early days of
Mozilla, I know the bad consequences of installing over old program files). Same
results again. Quoting exactly what i did this time:
1. Renamed my working profile from $user\Application Data\Thunderbird to
$user\Application Data\Thunderbird.old, in order to test with a clean profile.
2. Deleted c:\thunderbird, 
3. Checked Add/Remove Programs for thunderbird entry (there wasn't any).
4. Checked for program folder in c:\Program files (there wasn't any).
5. Unzipped the branch (static) build I downloaded today (version 0.6+
20040604). Didn't check the installer build.
6. Run the application account wizard and then (without altering anything or
installing extentions etc) Ilooked at Tools-Options-Fonts. Select box is still
unusable.

Please tell me if I missed something. Otherwise, can you reproduce the bug by
using the steps above, with the zipped build? I use Win2k/SP3.

Comment 5

[Dimitrios]

Did some addional testing with today's zipped branch and trunk builds (always
erasing the program directory first). 
- Trunk build behaves correctly when creating profile from scratch. Chrome.rdf
is 4K large. See "good" attachment.
- Branch build always shows the problem, even when starting with new profile.
Chrome.rdf is corrupted (1k size). See "bad" attachment. 
- Branch build corrupts the chrome.rdf of an existing (good) profile.
- After corrupting the chrome.rdf by using a branch build on a good profile and
then deleting the chrome.rdf, trunk build cannot recreate a good chrome.rdf.

Comment 6

[Dimitrios]

Attachment: "good" rdf created by trunk build

Comment 7

[Dimitrios]

Attachment: "bad" rdf created by branch build

Comment 8

[Scott MacGregor]

Thanks for helping out Dimitrios.

Question. Which chrome.rdf file is getting generated like this? The one in the
installation chrome directory? (i.e. C:\Program files\Mozilla
Thunderbird\chrome\chrome.rdf) or a chrome.rdf file in the user profile directory?

I don't see this issue but I always use the installer. I wonder if this is a
problem with how the zip build is generated verses the installer. 

Comment 9

[Scott MacGregor]

Hmmm. If I unzip a branch nightly:

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-0.7/

and look at thunderbird\chrome\installed-chrome.txt it looks complete. When I
then run the build for the first time this installed-chrome.txt file gets
converted into  a chrome.rdf file. And for me on Windows, I end up with a
chrome.rdf file that looks like your "Good rdf created by trunk build" attachment.

What does your installed-chrome.txt look like before you launch the zip build
for the first time?

Comment 10

[Dimitrios]

>Question. Which chrome.rdf file is getting generated like this? 

Thank you for looking into this. It's about the chrome file in the user's
profile directory. In the next hour, I'll download an installer and a zip build
(being frustrated I erased them all from the home pc :-( ). Then I'll check the
installed-chrome.txt.

Comment 11

[Dimitrios]

With an installer branch build from
http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-0.7/, same
problem. Now I noticed that character encoding menu in compose message window is
also empty. So this bug is similar or maybe identical to bug 245482 and bug 242043.

>What does your installed-chrome.txt look like before you launch the zip build
>for the first time?

Seems good and identical to that the trunk zipped build.

Comment 12

[Dimitrios]

Forgot to say that, when the chrome.rdf is corrupted, then by simply replacing
it with the uncorrupted ("good" attachment mentioned above) file the issue is
resolved.

Comment 13

[Scott MacGregor]

Hmm so now we need to figure out why when you download it the file gets
corrupted but not when I do it. 

Comment 14

[Dimitrios]

1. Is the following related? When I erase chrome.rdf in user profile, even the
trunk build is not able to regenerate it in the correct state.

2. Which jar this file comes from?

Comment 15

[Scott MacGregor]

Dimitrious, can you give me the full path to the chrome.rdf file that you see
get corrupted in your profile?

The only chrome.rdf file I have is in my program Files\thunderbird\chrome
directory and gets generated from installed-chrome.txt.

Unless you start installing extensions then you get a chrome.rdf file in
profile\chrome.

by the way, are you running with any extensions right now?

Comment 16

[Dimitrios]

>can you give me the full path to the chrome.rdf file that you see
>get corrupted in your profile?

..\Application Data\Thunderbird\Profiles\default.z4r\chrome\chrome.rdf

I don't use extensions at all. In ..\Application
Data\Thunderbird\Profiles\default.z4r\extensions there is only an extensions.rdf
file.

Comment 17

[Dimitrios]

Attachment: file activity taken from SysInternals FileMon

FileMon (from www.sysinternals.com) revealed the following file access during
the first run of the branch build. One clearly sees that thunderbird.exe
creates thunderbird\chrome\chrome.rdf then checks the existence of the
..\profile\...\chrome\chrome.rdf and it creates it if it doesn't exist.
Subsequent file writes create the content of that file.

Comment 18

[Scott MacGregor]

*** Bug 245482 has been marked as a duplicate of this bug. ***

Comment 19

[Dimitrios]

Happy for seeing it working on 20040608 branch zipped build (two different
machines tested). Not happy for not knowing the reason :-) I am not resolving as
wfm at the moment, in order to test the next few days builds. I am afraid that,
without knowing the real cause, we 'll see it in the future.

Comment 20

[Scott MacGregor]

wow. I have no idea what could have made this start working. I won't complain
though. 

Comment 21

[Scott MacGregor]

re-opening. I found a fix for this

Comment 22

[Scott MacGregor]

Attachment: the fix, stop looking in navigator.properties for the locale information

Comment 23

[Scott MacGregor]

*** Bug 245482 has been marked as a duplicate of this bug. ***

Comment 24

[Scott MacGregor]

fixed on the branch and the trunk

Comment 25

[Mike Cowperthwaite]

*** Bug 242536 has been marked as a duplicate of this bug. ***