Closed
Bug 576430
Opened 15 years ago
Closed 15 years ago
Autoconfiguration with mozilla.cfg no longer works on trunk, gives: "Failed to read the configuration file. Please contact your system administrator."
Categories
(Firefox :: Settings UI, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | final+ |
People
(Reporter: bugdickvl, Assigned: james-p)
References
Details
Attachments
(1 file)
543 bytes,
patch
|
jorendorff
:
review+
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•15 years ago
|
||
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•15 years ago
|
||
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•15 years ago
|
||
I believe it is this changeset
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=da9e50cb4091&tochange=ffbc3baf03ae
Assignee | ||
Comment 4•15 years ago
|
||
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•15 years ago
|
||
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 6•15 years ago
|
||
James, would you be willing to attach your patch to the bug instead of pasting it in a comment, and request review from jorendorff@mozilla.com?
Assignee: nobody → james-p
blocking2.0: --- → final+
Flags: in-litmus?
Comment 7•15 years ago
|
||
bsmedberg:
Is this the right "fix"
I'm wondering why the tracemonkey changes caused this...
Assignee | ||
Comment 8•15 years ago
|
||
Attachment #457858 -
Flags: review?(jorendorff)
Comment 9•15 years ago
|
||
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•15 years ago
|
||
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+
Comment 11•15 years ago
|
||
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.
Reporter | ||
Comment 12•15 years ago
|
||
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);
Reporter | ||
Comment 13•15 years ago
|
||
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•15 years ago
|
||
Sounds like you could probably write an xpcshell test for that.
Reporter | ||
Comment 15•15 years ago
|
||
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•15 years ago
|
||
dickvl: please file another bug for that.
Reporter | ||
Comment 17•15 years ago
|
||
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.
Assignee | ||
Comment 18•15 years ago
|
||
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
Assignee | ||
Comment 19•15 years ago
|
||
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•15 years ago
|
||
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
Comment 22•15 years ago
|
||
Shawn is sheriffing in my place today though I may be able to land it when I'm back later.
Comment 23•15 years ago
|
||
(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•15 years ago
|
||
Comment on attachment 457858 [details] [diff] [review]
[checked-in] Add JSCLASS_IS_GLOBAL flag
http://hg.mozilla.org/mozilla-central/rev/308d7847bbb4
Attachment #457858 -
Attachment description: Add JSCLASS_IS_GLOBAL flag → [checked-in] Add JSCLASS_IS_GLOBAL flag
Updated•15 years ago
|
Comment 25•14 years ago
|
||
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?
Assignee | ||
Comment 26•14 years ago
|
||
New bug - now fixed in bug 590325 (also see bug 595522), but not fixed in Beta 9
Comment 27•14 years ago
|
||
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.
Assignee | ||
Comment 28•14 years ago
|
||
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.
Description
•