Closed Bug 786875 Opened 8 years ago Closed 7 years ago

The defaultPref command in mozilla.cfg no longer works


(Core :: Preferences: Backend, defect, critical)

14 Branch
Windows 7
Not set





(Reporter: harry, Unassigned)



(1 file)

Using a defaultPref command in mozilla.cfg no longer changes the default value for the preference.  The lockPref command still works.  (See discussion at 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
Severity: normal → critical
Confirmed in FF15.

We really need some tests for this stuff, but I have no idea how to write them.
Ever confirmed: true
Regression window:

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("", 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.
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 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.
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

about=Mozilla Firefox EME-free

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.