Closed Bug 841011 Opened 9 years ago Closed 8 years ago
Autoconfiguration via mozilla
.cfg no longer works in Nightly: "Failed to read the configuration file . Please contact your system administrator ."
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).
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.
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.
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
Closed: 9 years ago
Resolution: --- → FIXED
oops, meant to change that from unconfirmed -> new.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: FIXED → ---
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.
(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/
(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?
Status: REOPENED → RESOLVED
Closed: 9 years ago → 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla22
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+
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.