395660 - Autoconfig over all.js in folder greprefs doesn't work, TB fails to start

Status: RESOLVED INCOMPLETE

(Thunderbird :: General, defect)

Description

[Alexandros Gougousoudis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Version 2.0.0.6 (20070728)

I edited the all.js file in folder greprefs/ to have that content:

[...]
pref("general.config.obscure_value", 0);
pref('general.config.filename', 'sc-ittb.txt'); 

where the file sc-ittb.txt is in the folder above greprefs, where the thunderbird.exe is. 

In sc-ittb.txt is this:
lockpref("app.update.enabled", false);
lockpref("app.update.auto", false); 
lockpref("mailnews.start_page.enabled", true);
lockpref("mailnews.start_page.url", "http://www/"); 

As it's mentioned everywhere on the net, and as it works under Firefox. 

Now everytime I start Thunderbird, the progam says it can't find the config file and I should contact the administrator. I can only click ok, and thats all.

Reproducible: Always

Steps to Reproduce:
1. create / modify a all.js with general.config.filename in folder greprefs
2. create a file with the filename above in the folder where thunderbird.exe is in.
3. see Thunderbird fail to start
Actual Results:  
Thunderbird failed to start.

Expected Results:  
Thunderbird should take over the locked preferences in the file, named by the general.config.filename object to let the admin preset some settings of Thunderbird.

- I also did a ROT13 transformation of the txt file and changed the obscure value back to 13. No success.

- I copied the txt file nearly everywhere in the thunderbird directory tree, to see where the file is read from. No success.

- I copied the all.js also into defaults/pref folder, where it's read, but TB still fails to start. No success.

- made an strace in windows to see where TB tries to read it from (that wasn't clear enough in the log)

Comment 1

[Laurent Bauvens]

I confirm this behaviour with 2.0.0.6. 

The issue seems to be solve at least in the version 2.0.0.12pre (20080128)

http://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/latest-mozilla1.8/thunderbird-2.0.0.12pre.en-US.win32.zip

Comment 2

[Wayne Mery (:wsmwk)]

Laurent, thanks for checking that. It is possible for you/Alexandros to verify this also fails with most recent beta?  

http://www.mozillamessaging.com/en-US/thunderbird/early_releases/  
(backup your profile before testing.

Comment 3

[Laurent Bauvens]

I have tested Alexandros' method with [Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2] and this MCD variant usage works fine.

I just remark that pref keys which are lockpref'ed are not saved in the prefs.js where they continue to exist with their old values. I can't say whether or not it is a normal behaviour. I am rather accustomed to using the standard MCD method where all lockpref'ed keys are saved in the prefs.js with their new values.

Comment 4

[Peeter Marvet]

Is it possible that the problem is related to improper capitalization of "lockpref" in the steps above? I was able to reproduce the problem on 2.0.0.21 UNTIL I changed it to lockPref, then everything seemed to work...

Comment 5

[Wayne Mery (:wsmwk)]

who do we know that understands pref precedence and setup?

Comment 6

[Wayne Mery (:wsmwk)]

(pinging bugs marked version 2.0)

Do you also see this problem in version 3.1? 
  http://getthunderbird.com/

If you do not, please close the bug with status set to RESOLVED and resolution set to WORKSFORME.

Comment 7

[Joshua Cranmer [:jcranmer]]

RESOLVED INCOMPLETE due to lack of response to previous comment. If you feel this change was made in error, please respond to this bug with your reasons why.