Closed Bug 395660 Opened 13 years ago Closed 10 years ago

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


(Thunderbird :: General, defect)

Windows 2000
Not set


(Not tracked)



(Reporter: gougousoudis, Unassigned)


(Whiteboard: closeme 2010-12-01)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv: Gecko/20070725 Firefox/
Build Identifier: Version (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("", 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)
Version: unspecified → 2.0
I confirm this behaviour with 

The issue seems to be solve at least in the version (20080128)
Laurent, thanks for checking that. It is possible for you/Alexandros to verify this also fails with most recent beta?  
(backup your profile before testing.
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.
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 UNTIL I changed it to lockPref, then everything seemed to work...
who do we know that understands pref precedence and setup?
(pinging bugs marked version 2.0)

Do you also see this problem in version 3.1?

If you do not, please close the bug with status set to RESOLVED and resolution set to WORKSFORME.
Whiteboard: closeme 2010-12-01
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.
Closed: 10 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.