Autoconfiguration via mozilla.cfg no longer works in Nightly: "Failed to read the configuration file. Please contact your system administrator."

RESOLVED FIXED in Firefox 21

Status

()

--
major
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: bugdickvl, Assigned: glandium)

Tracking

({regression})

21 Branch
mozilla22
x86
All
regression
Points:
---

Firefox Tracking Flags

(firefox20 unaffected, firefox21+ fixed, firefox22 fixed)

Details

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
I use a mozilla.cfg file to set some prefs to a specific value for all profiles.

When starting the Nightly build I get this error message:
"Failed to read the configuration file. Please contact your system administrator."

This build works:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-02-11-03-10-55-mozilla-central/

This build gives the error message:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2013-02-12-03-11-20-mozilla-central/

STR:
1. local settings.js with this content in Nightly /defaults/pref directory
pref("general.config.filename", "mozilla.cfg");
pref("general.config.obscure_value", 0);

2. mozilla.cfg with this content
// 
pref("browser.startup.homepage", "about:about");
pref("browser.newtab.url", "about:blank");

See also:
http://kb.mozillazine.org/Locking_preferences

We could use some tests with mozilla.cfg as this doesn't happen for the first time (Bug 576430).
That would be http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5835bc763be7&tochange=36525224b14e
tracking-firefox21: --- → ?
Keywords: regression
Unfortunately the QA team says there's no way to create a test for it.
Looking through the patches, I see nothing of consequence except this major change:

https://bugzilla.mozilla.org/show_bug.cgi?id=755724
Moving your mozilla.cfg to the browser sub-dir solves this, which happens to be the working directory when we look for it. Not sure if this is expected, cc'ing mike.

Updated

6 years ago
Blocks: 755724
Component: Preferences → Preferences: Backend
Product: Firefox → Core
Tracking since this will largely affect our ESR users - assigning to Glandium initially since he is the owner of the regressed bug.
Assignee: nobody → mh+mozilla
status-firefox20: --- → unaffected
status-firefox21: --- → affected
tracking-firefox21: ? → +
This won't be too hard to touch up if we want to. The currently read routine uses NS_XPCOM_CURRENT_PROCESS_DIR when opening the file:

http://mxr.mozilla.org/mozilla-central/search?string=openAndEvaluateJSFile

Although I can think of some cases where we might want to look in the app dir. Since we now support multiple apps within the same gre, different apps might have different lock files. Maybe we should check app and if we don't find anything, check gre for all applications.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
oops, meant to change that from unconfirmed -> new.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---
(Assignee)

Comment 8

6 years ago
Created attachment 715131 [details] [diff] [review]
Use the parent directory of XRE_EXECUTABLE_FILE to find autoconf file

This seems like the sensible thing to do for existing setups to continue working (including FF-on-xulrunner)
Attachment #715131 - Flags: review?(benjamin)
I'm concerned about other things here to.

Did the distribution directory move under browser?

I assume defaults\pref and defaults\profile moved under browser?

And the extensions directory for extensions?

This is a MAJOR documentation overhaul.
(Assignee)

Comment 10

6 years ago
(In reply to Michael Kaply (mkaply) from comment #9)
> I'm concerned about other things here to.
> 
> Did the distribution directory move under browser?

I think so, but that should probably be changed if that's the case. Can you file a separate bug for that?

> I assume defaults\pref and defaults\profile moved under browser?

defaults/pref no. defaults/profile hasn't been a directory for a while (it was in omni.ja ; and now it's in browser/omni.ja)

> And the extensions directory for extensions?

extensions should go in distribution/extensions, shouldn't they?
(In reply to Mike Hommey [:glandium] from comment #10)
> (In reply to Michael Kaply (mkaply) from comment #9)
> > I assume defaults\pref and defaults\profile moved under browser?
> 
>  defaults/profile hasn't been a directory for a while (it
> was in omni.ja ; and now it's in browser/omni.ja)

defaults/profile is still read and used if it is present. It's an easy way for an enterprise to deploy a custom bookmarks file by placing in in defaults/profile.

See:

http://mike.kaply.com/2012/03/30/customizing-firefox-default-profiles/

> And the extensions directory for extensions?

extensions should go in distribution/extensions, shouldn't they?

There are multiple places extensions can be deployed for different reasons.

Placing extensions placed in the EXE\extensions directory is a common practice because they can't be uninstalled by the user (although they can be disabled).

This is different than distribution/extensions which causes the extension to be installed, or distribution/bundles which reads the chrome.manifest but doesn't really install the extension.
>> I assume defaults\pref and defaults\profile moved under browser?

>defaults/pref no. 

Sorry, I meant defaults/preferences. Should that directory be created under browser now?

See:

http://mike.kaply.com/2012/03/15/customizing-firefox-default-preference-files/
(Assignee)

Comment 13

6 years ago
(In reply to Michael Kaply (mkaply) from comment #12)
> >> I assume defaults\pref and defaults\profile moved under browser?
> 
> >defaults/pref no. 
> 
> Sorry, I meant defaults/preferences. Should that directory be created under
> browser now?

Yes, but you can still use defaults/pref.

> See:
> 
> http://mike.kaply.com/2012/03/15/customizing-firefox-default-preference-
> files/

Note that blog post is confusion because it mentions defaults/preferences and then says to place files in defaults/pref.
> Note that blog post is confusion because it mentions defaults/preferences and then says to place files in defaults/pref.

I'll fix that, but the source of confusion is that you now have to put files in defaults/preferences instead of defaults/pref after Firefox 14. That post was written before Firefox 14.

You should not use defaults/pref.

See:

http://mike.kaply.com/2012/08/01/major-change-setting-default-preferences-for-firefox-14/

or

https://bugzilla.mozilla.org/show_bug.cgi?id=779437
I've done some research and browser/defaults/preferences is the place to put the preferences file.

Also, adding files to browser/defaults/profile does cause them to get copied over to the profile.

So all the documentation for defaults will need to be updated (again).

Is the Metro version of Firefox going to have a separate profile from the regular Firefox?
Comment on attachment 715131 [details] [diff] [review]
Use the parent directory of XRE_EXECUTABLE_FILE to find autoconf file

I think this is ok. Not that any other app is going to care about pref autoconfig anyway.
Attachment #715131 - Flags: review?(benjamin) → review+
I really think we need input from kev needham's team on this
Bah. wrong bug. I had a different question for this one.

Do we ever picture a world where other apps are in this directory along with browser (thunderbird for instance)

Is the autoconfig about the app or the browser?

And will the metro Firefox read autoconfig?
https://hg.mozilla.org/mozilla-central/rev/179a23a14368
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
(Assignee)

Comment 21

6 years ago
Comment on attachment 715131 [details] [diff] [review]
Use the parent directory of XRE_EXECUTABLE_FILE to find autoconf file

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 755724
User impact if declined: existing mozilla.cfg setups stop working
Testing completed (on m-c, etc.): Validated it works with latest nightly.
Risk to taking this patch (and alternatives if risky): Low
String or UUID changes made by this patch: None
Attachment #715131 - Flags: approval-mozilla-aurora?
Attachment #715131 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/c15b6ac9ec65
status-firefox21: affected → fixed
status-firefox22: --- → fixed

Comment 23

5 years ago
I'm new to this so I don't understand fom the comments how I can fix this so it will work. Can someone please help me?
You need to log in before you can comment on or make changes to this bug.