Closed Bug 576430 Opened 13 years ago Closed 13 years ago

Autoconfiguration with mozilla.cfg no longer works on trunk, gives: "Failed to read the configuration file. Please contact your system administrator."


(Firefox :: Settings UI, defect)

Not set



Tracking Status
blocking2.0 --- final+


(Reporter: bugdickvl, Assigned: james-p)




(1 file)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100625 Firefox/3.6.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:2.0b2pre) Gecko/20100701 Minefield/4.0b2pre

autoconfiguration with mozilla.cfg to set or lock prefs no longer works on trunk.
If I place a file local-settings.js in the defaults/pref folder and mozilla.cfg in the main Mozilla program folder then I get this error message:
"Failed to read the configuration file. Please contact your system administrator."

Reported here on MozillaZine:

Have the instructions or location of mozilla.cfg been changed?

Found this regression range on Linux:
2010-05-24-03 : works.
2010-05-25-03 : gives error message and Minefield doesn't start.

Reproducible: Always

Steps to Reproduce:
1. local settings.js with content pref("general.config.filename", "mozilla.cfg"); in Minefield/defaults/pref
2. mozilla.cfg, byte-shifted with offset 13, in the Minefield program folder
3. Cleared profile folder to make Minefield create a new profile folder.
Actual Results:  
The 2010-05-24-03-mozilla-central version works as expected and lock the prefs.

The 2010-05-25-03-mozilla-central version gives the "Failed to read the configuration file. Please contact your system administrator." error message and aborts starting.
Only a few files are created in the profile folder and prefs.js only has some extensions related prefs.

Expected Results:  
Both versions should start and the prefs should be locked according to the content of mozilla.cfg
Version: unspecified → Trunk
I've just had a similar problem with 4.0b1

Running with NSPR_LOG_MODULES=all:4 gives:

-158406960[f660f060]: general.config.filename = local.cfg
-158406960[f660f060]: JS error in js from MCD server: out of memory
Do you still have those two Linux builds?

Can you run about:buildconfig on the 5-25-03 one and list the changes sets from that build?
I downloaded the 4.0b1 source and built the debug version - which errors, when using "general.config.filename", with:

Assertion failure: clasp->flags & JSCLASS_IS_GLOBAL, at ./mozilla-central/js/src/jsapi.cpp:2777

Running through gdb, this is happening in CentralizedAdminPrefManagerInit() (in extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp) 

Looking at nsJSConfigTriggers.cpp - it has:

static JSClass global_class = {
    "autoconfig_global", 0,

i.e. the JSCLASS_IS_GLOBAL flag is indeed not set ... setting this flag and it appears to work ... the following patch is what I used - although I have no idea if this is a proper fix, as I've never looked at the mozilla source before now ...

--- ./mozilla-central/extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp.dist2010-06-30 21:07:58.000000000 +0100
+++ ./mozilla-central/extensions/pref/autoconfig/src/nsJSConfigTriggers.cpp    2010-07-16 14:20:32.903589625 +0100
@@ -108,7 +108,7 @@
 static  JSObject *autoconfig_glob;

 static JSClass global_class = {
-    "autoconfig_global", 0,
+    "autoconfig_global", JSCLASS_GLOBAL_FLAGS,
     JS_PropertyStub,  JS_PropertyStub,  JS_PropertyStub,  JS_PropertyStub,
     JS_EnumerateStub, JS_ResolveStub,   JS_ConvertStub,   nsnull

Very nice job,.

This definitely then seems to point to the tracemonkey checkin that happened in that range. I'll try to find a JavaScript person to figure out if this is the right fix.
Ever confirmed: true
James, would you be willing to attach your patch to the bug instead of pasting it in a comment, and request review from
Assignee: nobody → james-p
blocking2.0: --- → final+
Flags: in-litmus?

Is this the right "fix"

I'm wondering why the tracemonkey changes caused this...
Attachment #457858 - Flags: review?(jorendorff)
I think it is, but jorendorff would know best. I believe that the JSClass for global objects is required to have JSCLASS_IS_GLOBAL. This would probably assert in a debug build, but we apparently don't have any automated tests for this case.

I'd love for somebody to create one!
Comment on attachment 457858 [details] [diff] [review]
[checked-in] Add JSCLASS_IS_GLOBAL flag

This is the right fix.

Do we have any test coverage for autoconfig? What can I do to help?
Attachment #457858 - Flags: review?(jorendorff) → review+
So I can describe what a test scenario like this would look like. I'm honestly not sure how to do it.

It would involve a default pref file that had these two lines in it:

pref("general.config.obscure_value", 0);
pref("general.config.filename", "mozilla.cfg");

Then a file called mozilla.cfg there the Firefox executable was located that looked like this
lockPref("browser.startup.homepage", ""); (or some website)

Then verify that page displays when the browser comes up.

And locking can be checked by trying to set the pref and then querying it.
Possible code to test for a locked pref:

const Cc=Components.classes;
const Ci=Components.interfaces;

var prefBranch=Cc[";1"].

prefName = "browser.startup.homepage";
prefLocked= prefBranch.prefIsLocked(prefName);
Had forgotten to remove remove some excessive code when modifying an example.
Sorry for the bug spam.

const Cc=Components.classes;
const Ci=Components.interfaces;

var prefBranch=Cc[";1"].

prefName = "browser.startup.homepage";
prefLocked= prefBranch.prefIsLocked(prefName);
Sounds like you could probably write an xpcshell test for that.
dickvl: please file another bug for that.
Done, filed bug 584169

Can someone set dependencies and/or blocking data as I'm not that much familiar with doing that.
I would assume that bug 584169 will prevent testing fixes from this bug, so that bug needs to be fixed first.
Isn't this the same problem?

Downloading and building the latest Mercurial source, it SEGVs when using a mozilla.cfg file

Applying the patch (attachment 457858 [details] [diff] [review]) and it starts up fine with a mozilla.cfg file
Just out of interest, what is the next step in in getting this issue fixed?

i.e. how does the patch get accepted?
Ah. Technically you're the bug owner, which means you're responsible for getting this landed in the tree. But I guess you didn't know that, which is understandable. I'm going to set the checkin-needed flag and cc the sheriff for today, who can probably get this checked in if the tree is green.
Keywords: checkin-needed
Shawn is sheriffing in my place today though I may be able to land it when I'm back later.
(In reply to comment #22)
> Shawn is sheriffing in my place today though I may be able to land it when I'm
> back later.
It's likely not landing today due to tree issues.
Comment on attachment 457858 [details] [diff] [review]
[checked-in] Add JSCLASS_IS_GLOBAL flag
Attachment #457858 - Attachment description: Add JSCLASS_IS_GLOBAL flag → [checked-in] Add JSCLASS_IS_GLOBAL flag
Closed: 13 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
I'm getting this error with Beta 9 when I try to set my config file name in general.config.filename from greprefs.js and firefox won't start.  Is this still an issue?
New bug - now fixed in bug 590325 (also see bug 595522), but not fixed in Beta 9
I pulled the nightly build (4.0b10pre) and it fails there as well.  Is there a way I can pull the fix into my firefox install file.  I'm not a firefox developer, I just need to update the install file with some custom configuration.
I can make it work if I copy in the contents of defaults/autoconfig/ from a previous beta release to defaults/autoconfig/ of the most recent nightly build (this is on Linux) and either add the general.config.filename entries to defaults/pref/channel-prefs.js or create a custom .js file in defaults/preferences/

See bug 595522 for more details
You need to log in before you can comment on or make changes to this bug.