Closed Bug 439695 Opened 13 years ago Closed 9 years ago

Preferences Ignored

Categories

(Firefox :: Preferences, defect)

3.6 Branch
x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 451161

People

(Reporter: tenninjas, Unassigned)

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

Any preference set via defaultPref() using autoconfig is ignored - preferences in same autoconfig set via lockPref() work fine. Preference changes made via about:config as well as manually editing prefs.js are not saved. Preference changes made via Tools -> Options UI are not saved. 

I have tried this on 4 different computers now, with identical results. One of the computers has never previously had Firefox installed, and all 4 were clean installs (no old profiles present on the machine, previous FF removed cleanly, rebooted).

I am curious if someone else can reproduce this problem or not, as I'd think there would be more 'noise' about it if it was very common.


Reproducible: Always

Steps to Reproduce:
1. Install Firefox, but do not launch.

2. Create 'FFDIR\defaults\pref\all.js' file:

pref("general.config.obscure_value", 0);
pref("general.config.filename", "mozilla.cfg"); 

3. Add any valid preferences to FFDIR\mozilla.cfg; one as lockPref and another as defaultPref; for example:

defaultPref("browser.cache.disk.capacity", 131072);
lockPref("browser.cache.disk.parent_directory", "C:\\Temp\\");

4. Launch Firefox.

5. Change preference via Tools -> Options UI, or about:config.

6. Quit and restart Firefox.
Actual Results:  
The preference set via lockPref will be set and locked correctly. The preference set via defaultPref will be ignored. After restarting, any changes will be lost. Even if the autoconfig file and data is removed, preferences will still not save.

Expected Results:  
The preference set via defaultPref should work correctly.

I have tested this with the following preferences, which are all ones that previously worked correctly:

browser.download.*
browser.history_expire_days.*
browser.search.*
network.cookie.*
privacy.item.*
browser.cache.*
Have done more testing, seems defaultPrefs are being over-ridden somewhere, as if I set nonsense values they work fine and are visible.

Has the place we need to import these preferences changed?
Files:
FFDIR\defaults\profile\prefs.js
FFDIR\defaults\profile\user.js

Are also being ignored.
I am seeing similar, though not identical, behaviour with the Linux version of 3.0 (Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.9) Gecko/2008052912 Firefox/3.0).

My defaultPref directives succeed in setting the preference, but they do so every time the browser is started, even if the user has changed the preference. I found this behaviour both with image.animation_mode (changed via about:config) and security.enable_java (changed via user interface).

As an experiment I tried removing Pref entries from greprefs/all.js, and it then became possible for the user to make persistent changes. However, this is not a good solution because it completely defeats the object of putting site customisations in a centralised location.
After further thought I think there are two issues here:

(1) the confusing state of the Preference documentation has led TenNinjas to apply the preferences incorrectly. If you look at

http://developer.mozilla.org/en/docs/Automatic_Mozilla_Configurator:Locked_config_settings

there is a crucial line stating that all.js has moved from defaults/pref to greprefs: could you try editing this instead? 

(2) I suspect there might be a flaw in the compression algorithm used when Firefox saves preferences: if a user preference is the same as the one in all.js it does not get saved. However the algorithm needs to take into account defaultPref directives as well.  
In reply to (1) from the previous comment... I have applied the preferences via all possible locations. The reason it is preferable to apply via defaults\pref\all.js is because, if you observe loading order, this is the last location to be read prior to loading user-specific preferences.

There is absolutely no difference when applying the same preferences via greprefs/all.js
spent couple of days reproducing the problem (on Thunderbird) before I found this report - and it reproduces loud and clear (in addition stepped on bug 490532 that manages to avoid interpreting first line of .cfg file)

and yes, like Bob notes, changing/replacing the "default default" helps (but I'd really like to avoid doing that with every TB/FF update)
I was able to reproduce this bug with Firefox 3.5.2 on Win XP Pro 32-bit. I set "general.config.obscure_value" and "general.config.filename" in the end of greprefs/all.js and add a file firefox.cfg containing my lockPref and defaultPref calls. The function lockPref works fine, but defaultPref does not seem to make any difference. Apparently locking the preferences protects them from being re-set later in the program code.

To find out where the defaults get re-set I tried to add an observer to the default preferences branch (retrieved using getDefaultBranch), but apparently it is only possible to observe normal branches (retrieved using getBranch function).
After investigating this bug more, I discovered that there was some kind of problem in my Firefox 3.5.2 installation. I did not use a clean install when I last tested, but instead used an old installation which had been automatically upgraded several times. After doing a clean installation (first completely removing the old installation), both defaultPref and lockPref worked fine.

I'll try to compare my old C:\Program Files\Mozilla Firefox contents with the clean installation of 3.5.2 to find out the reason for the previous behaviour.
I can reproduce it with 3.5.3 loud and clear.

You need to defaultPref something into non-default setting, then try to set it manually back to the original default value as defined in all.js

Let's say defaultPref("browser.cache.disk.capacity", 131072); as described above and then try making it back to 51200 using about:config (which, btw, is different from 50000 default value found in 3.0.10) - after restarting Firefox 3.5.3 it is back to 131072.
I can confirm this still occurs in Firefox 3.6.6 with browser.cache.disk.capacity. If you set the defaultPref to 131072, then set it to 51200 in about:config, it will go back to 131072 on next run. (However, it appears to have been fixed for network.proxy.type as in bug 451161).

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
As far as I can tell, the problem is, if you change a pref from the value that was set with defaultPref to the initial default value of Firefox, it doesn't get saved as user set, but as default. So it get's overwritten again with the autoconfig defaultPref at next restart.
Version: unspecified → 3.6 Branch
I can confirm that this bug is present in firefox 5.0.0 too. I've added some infos more in https://bugzilla.mozilla.org/show_bug.cgi?id=451161 because I think the two bugs are the same duplicated bug.

It is not still the time to change the status in confirmed? 

Have a nice day

Piviul
defaultPref is ignored also in Thunderbird 5.0.
defaultPref is exhibiting this bug with Firefox 8.0 on Mac OS.
defaultPref() is ignored completely in Firefox 7.0.1 running on Ubuntu 11.04.

See my comment here as well:

  https://bugzilla.mozilla.org/show_bug.cgi?id=451161#c14
Status: UNCONFIRMED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 451161
You need to log in before you can comment on or make changes to this bug.