Closed
Bug 786875
Opened 12 years ago
Closed 12 years ago
The defaultPref command in mozilla.cfg no longer works
Categories
(Core :: Preferences: Backend, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: harry, Unassigned)
Details
Attachments
(1 file)
45 bytes,
text/plain
|
Details |
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.
Updated•12 years ago
|
Component: Preferences → Preferences: Backend
Product: Firefox → Core
Updated•12 years ago
|
Severity: normal → critical
Comment 1•12 years ago
|
||
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
Comment 2•12 years ago
|
||
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...
Comment 3•12 years ago
|
||
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.
Comment 4•12 years ago
|
||
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.
Reporter | ||
Comment 5•12 years ago
|
||
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?
Comment 6•12 years ago
|
||
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: 12 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.
Comment 8•9 years ago
|
||
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"
Comment 10•9 years ago
|
||
Yeah, this is a longstanding bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=947838
Comment 11•9 years ago
|
||
Aah... What's the role of distribution.ini? Can I safely delete it? Any side effects?
Comment 12•9 years ago
|
||
> 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.
Comment 13•9 years ago
|
||
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.
Description
•