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

Status: RESOLVED FIXED

(Firefox :: Settings UI, defect)

Description

[dickvl]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.6) 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: http://forums.mozillazine.org/viewtopic.php?f=23&t=1930235

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

http://kb.mozillazine.org/Locking_preferences 
https://developer.mozilla.org/en/Automatic_Mozilla_Configurator/Locked_config_settings

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

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/05/2010-05-24-03-mozilla-central/firefox-3.7a5pre.en-US.linux-i686.tar.bz2
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010/05/2010-05-25-03-mozilla-central/firefox-3.7a5pre.en-US.linux-i686.tar.bz2

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

Comment 1

[James Pearson]

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

Comment 2

[Mike Kaply [:mkaply]]

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?

Comment 3

[Mike Kaply [:mkaply]]

I believe it is this changeset

http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da9e50cb4091&tochange=ffbc3baf03ae

Comment 4

[James Pearson]

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
 };

Comment 5

[Mike Kaply [:mkaply]]

James:

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.

Comment 6

[Benjamin Smedberg]

James, would you be willing to attach your patch to the bug instead of pasting it in a comment, and request review from [e-mail]?

Comment 7

[Mike Kaply [:mkaply]]

bsmedberg:

Is this the right "fix"

I'm wondering why the tracemonkey changes caused this...

Comment 8

[James Pearson]

Attachment: [checked-in] Add JSCLASS_IS_GLOBAL flag

Comment 9

[Benjamin Smedberg]

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 10

[Jason Orendorff [:jorendorff]]

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?

Comment 11

[Mike Kaply [:mkaply]]

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", "http://.yahoo.com"); (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.

Comment 12

[dickvl]

Possible code to test for a locked pref:

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

var prefBranch=Cc["@mozilla.org/preferences-service;1"].
               getService(Ci.nsIPrefService).
               QueryInterface(Ci.nsIPrefBranch);

prefName = "browser.startup.homepage";
prefLocked= prefBranch.prefIsLocked(prefName);

Comment 13

[dickvl]

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["@mozilla.org/preferences-service;1"].
               getService(Ci.nsIPrefBranch);

prefName = "browser.startup.homepage";
prefLocked= prefBranch.prefIsLocked(prefName);

Comment 14

[(not currently active) Ted Mielczarek]

Sounds like you could probably write an xpcshell test for that.

Comment 15

[dickvl]

There is another regression.
Currently Minefield crashes immediately if I specify a mozilla.cfg file.

Crashes: BuildID=20100801030131 SourceStamp=070d9d46d88b
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-08-01-03-mozilla-central/firefox-4.0b3pre.en-US.linux-i686.tar.bz2

Works: BuildID=20100731030927 SourceStamp=f73e5032cfad
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2010-07-31-03-mozilla-central/firefox-4.0b3pre.en-US.linux-i686.tar.bz2

Changeset:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f73e5032cfad&tochange=070d9d46d88b

http://crash-stats.mozilla.com/report/index/bp-fce88062-081f-457a-91cf-0fbbf2100802

Comment 16

[timeless]

dickvl: please file another bug for that.

Comment 17

[dickvl]

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.

Comment 18

[James Pearson]

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

Comment 19

[James Pearson]

Just out of interest, what is the next step in in getting this issue fixed?

i.e. how does the patch get accepted?

Comment 20

[Benjamin Smedberg]

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.

Comment 22

[Dave Townsend [:mossop]]

Shawn is sheriffing in my place today though I may be able to land it when I'm back later.

Comment 23

[Shawn Wilsher :sdwilsh]

(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 24

[Rob Campbell [:rc] (:robcee)]

Comment on attachment 457858 [details] [diff] [review]
[checked-in] Add JSCLASS_IS_GLOBAL flag

http://hg.mozilla.org/mozilla-central/rev/308d7847bbb4

Comment 25

[Don Kleppinger]

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?

Comment 26

[James Pearson]

New bug - now fixed in bug 590325 (also see bug 595522), but not fixed in Beta 9

Comment 27

[Don Kleppinger]

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.

Comment 28

[James Pearson]

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