Closed Bug 786875 Opened 8 years ago Closed 7 years ago
Pref command in mozilla .cfg no longer works
Using a defaultPref command in mozilla.cfg no longer changes the default value for the preference. The lockPref command still works. (See discussion at https://support.mozilla.org/en-US/questions/933876 for more detail including a workaround.) I did some troubleshooting with Process Monitor and it appears to me that the default preferences files (greprefs.js, firefox.js, etc.) are being re-read after mozilla.cfg has been processed, overwriting the changes made in mozilla.cfg unless lockPref is used.
Component: Preferences → Preferences: Backend
Product: Firefox → Core
Confirmed in FF15. We really need some tests for this stuff, but I have no idea how to write them.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Regression window: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8f377102841b&tochange=cfaf90b22fc3 Unfortunately I see nothing is this changeset that looks like the culprit...
As a side note, when this first broke, defaultPref didn't work at all. For instance: defaultPref("foo", "bar"); did nothing. In the current build, that line works, but defaultPref("browser.startup.page", 0); still fails. I'm also going to track down when the first one started working again. That might help figure out what happened here.
defaultPref in general started working again: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=8b96a33ecbd2&tochange=2abd21593e57 This corresponds to when https://bugzilla.mozilla.org/show_bug.cgi?id=776490 was fixed.
When I originally reported this problem I was testing on Firefox 14.0.1. I thought I had seen the same problem on Firefox 15, but now I'm having trouble reproducing it. I may have been confused earlier because browser.startup.page is ignored on the first run due to the upgrade splash page, or perhaps I didn't have local-settings.js properly in place. @Michael: perhaps you should double-check that the problem really does exist in the release version of FF15?
It is working for me now as well. I have no explanation for why it is working. I'll just be happy.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
I came across the same problem. Win7, Firefox 48 -- Mozilla/5.0 (Windows NT 6.1; rv:48.0) Gecko/20100101 Firefox/48.0 1. Create Firefox\defaults\pref\autoconfig.js pref('general.config.filename', 'ac.js'); pref('general.config.obscure_value', 0); 2. Create Firefox\ac.js // defaultPref("accessibility.typeaheadfind", true); 3. Create new Firefox profile (to be sure) 4. Start it with that profile 5. Go to about:config 6. Expect: accessibility.typeaheadfind, default = true Actual: accessibility.typeaheadfind, default = false (no change) If defaultPref is replaced with pref or lockPref - works as expected.
Do you have a distribution.ini file in your distribution directory?
Yes, stock one: # Partner Distribution Configuration File # Author: Mozilla # Date: 2015-03-27 [Global] id=mozilla-EMEfree version=1.0 about=Mozilla Firefox EME-free [Preferences] media.eme.enabled=false app.partner.mozilla-EMEfree="mozilla-EMEfree"
Yeah, this is a longstanding bug: https://bugzilla.mozilla.org/show_bug.cgi?id=947838
Aah... What's the role of distribution.ini? Can I safely delete it? Any side effects?
> Aah... What's the role of distribution.ini? Can I safely delete it? Any side effects? Well in your situation, you're using the EME free version of Firefox so it's setting that preference (media.eme.enabled). You could set that preference elsewhere.
I see, so the only difference between normal and EME-free Firefox builds is that distribution.ini which changes About dialog and those two prefs. Thanks for the insight. Then removing the .ini and the following autoconfig should have the same effect, right? lockPref("media.eme.enabled", false); After the .ini is gone I can confirm that defaultPref works as expected.
You need to log in before you can comment on or make changes to this bug.