Last Comment Bug 451161 - defaultPref overwrites user prefs
: defaultPref overwrites user prefs
Status: RESOLVED FIXED
: dev-doc-needed
Product: Core
Classification: Components
Component: Preferences: Backend (show other bugs)
: unspecified
: All All
: -- normal with 5 votes (vote)
: mozilla11
Assigned To: Masatoshi Kimura [:emk]
:
Mentors:
: 439695 (view as bug list)
Depends on: 705983 738043
Blocks: fx-enterprise
  Show dependency treegraph
 
Reported: 2008-08-18 23:55 PDT by Carl
Modified: 2014-02-25 18:44 PST (History)
20 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments
patch (849 bytes, patch)
2011-11-10 05:05 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Review
patch v2 (78.79 KB, patch)
2011-11-16 09:55 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Review
Part 1: Allow overriding system accesibility settings without SystemPref module (5.89 KB, patch)
2011-11-19 07:26 PST, Masatoshi Kimura [:emk]
surkov.alexander: review+
Details | Diff | Review
Part 2: Remove SystemPref module from the tree (69.55 KB, patch)
2011-11-19 07:27 PST, Masatoshi Kimura [:emk]
roc: review+
Details | Diff | Review
Part 3: Reverse the reading order of user prefs and AutoConfig (926 bytes, patch)
2011-11-19 07:30 PST, Masatoshi Kimura [:emk]
roc: review+
Details | Diff | Review
Part 1: Allow overriding system accesibility settings without SystemPref module. r=surkov.alexander (5.91 KB, patch)
2011-11-25 10:48 PST, Masatoshi Kimura [:emk]
VYV03354: review+
christian: approval‑mozilla‑beta+
Details | Diff | Review
Folded part 1 to 3 of this bug and patches of bug 705983 and ported to beta; a=clegnitto (76.08 KB, patch)
2012-01-11 09:45 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Review

Description Carl 2008-08-18 23:55:19 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16

I'm trying to establish a global default proxy setting in an autoconfig script without preventing the user from overriding it. The usual defaultPref() and lockPref() calls work as expected for quite a variety of other settings, but not for network.proxy.type. The following line is undoing any proxy change the user attempts:

defaultPref("network.proxy.type", 1);

Reproducible: Always

Steps to Reproduce:
1. Write autoconfig script, including this line:

     defaultPref("network.proxy.type", 1);

2. Start Firefox.
3. Use Options dialog to change proxy to "Direct Connection To Internet".
4. Exit Firefox.
5. Restart Firefox.

Actual Results:  
Restarting Firefox and checking Options dialog for proxy setting shows that user's desired preference has been reverted to the defaultPref() value specified in autoconfig script.

Expected Results:  
I expect that all users that do not explicitly attempt to configure the proxy will get my specified default, which they do. I expect those that make a change to have that change survive restarting Firefox - this does not happen.
Comment 1 Carl 2008-08-22 14:22:00 PDT
I don't mean to irritate anyone by this comment, but the sound of crickets has me worried I've screwed up this bug submission somehow. Has it taken?
Comment 2 Carl 2008-09-09 18:49:05 PDT
Hello? Is there anybody out there? A simple acknowledgement should be the very least one can expect from submitting a bug. After all, you do want to encourage users to file bug reports, right? No? Hello?
Comment 3 Peeter Marvet 2009-04-29 09:22:15 PDT
this seems to be larger problem, related to defaultPref implementation (and not limited to this particular pref), see bug 439695
Comment 4 u88484 2009-06-27 12:55:11 PDT
This bug was reported using a version of Firefox that security and stability updates are no longer provided for.  All users are strongly encouraged to upgrade to Firefox 3 by selecting 'Check for Updates' in the Help menu or by going to http://www.mozilla.com/en-US/firefox/firefox.html

If you can no longer reproduce this bug using the latest Firefox 3.0.x version, please change the status of this bug to 'RESOLVED' 'WORKSFORME'.

If you can still reproduce this bug, please provide additional details to help resolve this issue.
Comment 5 Tyler Downer [:Tyler] 2009-09-14 08:05:09 PDT
No reply, INCOMPLETE. Please reply if you can still reproduce this bug with Firefox 3.5.3 or later in a new profile with the latest plugins (flash, quicktime, java, etc.).
Comment 6 Carl 2009-09-14 15:12:36 PDT
(In reply to comment #5)
> No reply, INCOMPLETE.

Are you serious?!? I provided details on how to reproduce the problem well over a year ago and no one saw fit to respond, much less verify the problem. As motivation to provide further input goes, that's not going to work.

When Peeter linked this with what looked to be a larger problem the following year, again there was no response. Eventually Kurt points out that so much time has gone by that the report can be neatly deflected by tossing the problem back at the user with the old "upgrade and reinvestigate it yourself" cliche. Well, I am in fact using Firefox 3.0 and have been for quite a while now, but haven't had the time or inclination to reinvestigate, particularly when history says I can be fairly certain no one will respect the effort enough to act upon it.

Now, Tyler, it's you asking me to upgrade to 3.5 and reinvestigate. I'm rather busy right now and filing bug reports that will be ignored for the next year isn't a high priority for me. Might I suggest that if the developers couldn't be bothered to investigate for 2.x that they probably didn't consciously fix it for 3.0 or 3.5? I spelled out how to reproduce the problem for 2.x, so perhaps you could try that procedure for 3.5 yourself?

For the record, triage is something one does *before* the patient dies.
Comment 7 Peeter Marvet 2009-09-15 04:35:18 PDT
While completely agreeing that bugs are unlikely to vanish without fixing... out of curiosity (and as Pauli seemed to think on related bugreport that it might have been fixed) I did try it with latest clean install of Firefox and can report, as copied from 439695:

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.
Comment 8 Tyler Downer [:Tyler] 2010-04-17 15:11:03 PDT
This bug was reported on Firefox 2.x or older, which is no longer supported and will not be receiving any more updates. I strongly suggest that you update to Firefox 3.6.3 or later, update your plugins (flash, adobe, etc.), and retest in a new profile. If you still see the issue with the updated Firefox, please post here. Otherwise, please close as RESOLVED > WORKSFORME
http://www.mozilla.com
http://support.mozilla.com/kb/Managing+profiles
http://support.mozilla.com/kb/Safe+mode
Comment 9 Carl 2010-04-18 00:51:03 PDT
Tyler, you really are infuriating. Are you going to pull this stunt indefinitely? Read comments 5, 6, and 7 in order. Seriously, go back and reread them, several times if necessary for comprehension.

Yes, I did report this problem for 2.x, but nothing was done. Peeter confirmed it was still present in 3.5.3, but still nothing was done. As in comment 6, I am not going to bother retesting for 3.6.3 because you'll do precisely nothing with the results I give you until a year from now when you tell me it's obsolete information and I should start all over again. I don't appreciate my time and effort being ignored.

It's a pretty safe bet the problem's still there in 3.6.3 since you've done nothing about it. This bug will likely continue to exist till hell freezes over, given your attitude. Go ahead, Tyler, prove me wrong.
Comment 10 Michael Kincaid 2010-06-30 19:02:18 PDT
This no longer seems to occur in FF 3.6.6. With a defaultPref of 1, after modifying network.proxy.type to 0 in the GUI/user profile, it remains at 0. (however it still seems to happen with other preferences - see bug 439695)

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.6) Gecko/20100625 Firefox/3.6.6
Comment 11 donaldledford 2011-05-24 13:58:14 PDT
I'd like to add I'm seeing the same behavior with several preferences under 4.0.1. Setting a pref in firefox.cfg using defaultPref will overwrite the user's current preference and if the user changes that preference the change does not stick between browser sessions.
Comment 12 Piviul 2011-06-23 05:30:44 PDT
I can confirm that this bug persists in firefox 5.0.0. 

I report my experience about this bug hoping that will help to better circumscribe this bug. 

If you use firefox.cfg to set default preferences, sometimes the default preference set in firefox.cfg prevent the user to change the value. I have wrote "sometimes" because this happens only if the default value set in firefox.cfg differs from the default firefox value. 

For example if there are no changes in preferences about the option Signon.rememberSignons the value of this option is true and this is in effect the default Firefox value for this option. If you set to false Signon.rememberSignons option in firefox.cfg when the user open ff the option is set to false as expected respecting the default value set in firefox.cfg. If the user change this option to true all seems to works (the user can memorize passwords) but when the browser is closed the preference is removed from prefs.js. When the user reopen ff the option is false again even if he has set it previously to true. In this case the value set in firefox.cfg prevent the user to change the option.
If in firefox.cfg the option Signon.rememberSignons is set to true, when the user open ff the option is set to true as expected and if the user change this option all works even after closing and reopening the browser.

I think the problem concern the way ff save prefs.js. When ff is closing it saves all options preferences in prefs.js and it inserts an option in prefs.js if and only if it differs from the default value. But the default value ff consider ignore the default value set in firefox.cfg

Please this bug has been reported 3 years ago I beg you, change the status bug in CONFIRMED and try to solve it!!!

Have a nice day

Piviul
Comment 13 Acheron 2011-06-24 08:51:18 PDT
I experience the same behaviour. Defaultpref worked fine when using Firefox 3.6.17 for most settings. After upgrading to Firefox 4.0.1 the defaultpref settings are ignored.
Comment 14 Carl 2011-11-09 21:26:00 PST
Well, it's been 1178 days since this bug was reported. Easily confirmed by others in Firefox 2.0, 3.5, 4.0, and 5.0. Duplicate bug 439695 was opened 1240 days ago and confirms the bug in Firefox 3.0, 3.5, 3.6, 5.0, and 8.0 and one person claims in Thunderbird 5.0 as well. Mozilla developers, OTOH, think both bug reports are still UNCONFIRMED and have yet to even assign either bug to anyone.

I recently did a fresh install of Ubuntu 11.04 with Firefox 7.0.1 (as opposed to Windows XP) and I'm here to report that it is no longer a subset of preferences that cannot be affected by defaultPref(), but *ALL* of them! lockPref() works as it should, but I cannot change the default for anything. Firefox is now more broken than before.

What exactly do end users have to do to get Mozilla developers to pay any attention to bug reports? I'm hoping that since Tyler Downer finally left Mozilla back in August that we've now got a chance of a competent triage replacement.

FWIW, I got an interesting result when I experimented with browser.privatebrowsing.autostart. I used defaultPref() to set it "true". I have the Session Manager add-on installed and when I started Firefox, the first thing I saw was a popup from Session Manager warning that "Your browser is currently set to start in Private Browsing Mode". However, after clicking OK and getting into Firefox, I checked about:config and found that browser.privatebrowsing.autostart is "false"! So its apparently true that defaultPref() usage is not ignored but apparently executes _before_ Mozilla's idea of good defaults overwrite preference defaults.

Like Piviul, I am begging. Please, please, please address this bug! I don't need rapid fire releases of an ever more broken web browser. What I need is a cross-platform web browser than can be properly administered.
Comment 15 Carl 2011-11-10 00:06:44 PST
I've been trying to come up with a workaround for this critical bug. While not exactly what I need, I thought I could include this snippet of code in a configuration file to provide an approximate substitute for defaultPref():

function setDefaultPref(prefName, value)
  {
  try
    {
    var prefBranch = getPrefBranch();
    if (!prefBranch.prefHasUserValue(prefName))
      pref(prefName, value);
    }
  catch(e)
    {
    displayError(version,
                 'setDefaultPref("' + prefName + '", ' + value + '): ', e);
    }
  }

A call to setDefaultPref() should then force the user's preference to the desired default value if and only if the user has not already set his own desired preference value. The flaw in that thinking can be found on this page:

  https://developer.mozilla.org/en/nsIPrefBranch#prefHasUserValue%28%29

where it says "If a preference was manually set to a value that equals the default value, then the preference no longer has a user set value, i.e. it is considered reset to its default value". IOW, Mozilla has designed the preferences system so that it is impossible to distinguish a user leaving a preference at its default value from a user who deliberately set the preference to a value which is coincidentally the same as the default. This would mean that my setDefaultPref() function will clobber a user's explicit desire to use a Mozilla-mandated value instead of my default - that's a bad thing. And in case anyone thinks this doesn't cause problems even in other scenarios, think about what happens when Mozilla changes a default in some future release. When that happens, preferences deliberately changed by the user from the original default are maintained, while those deliberately set by the user to the default mysteriously change without warning. That would be an obvious violation of the principle of least astonishment.

Can anyone come up with a solution that can be included in a configuration file to work around the completely broken defaultPref() functionality? It would be more than a major headache for us to dump Firefox right now in favour of a less broken web browser, but we need a way to set our own default preferences.
Comment 16 Masatoshi Kimura [:emk] 2011-11-10 05:03:51 PST
Confirming.
Comment 17 Masatoshi Kimura [:emk] 2011-11-10 05:05:19 PST
Created attachment 573487 [details] [diff] [review]
patch

This patch should fix the problem.
Comment 18 Masatoshi Kimura [:emk] 2011-11-10 05:07:34 PST
(In reply to Michael Kincaid from comment #10)
> This no longer seems to occur in FF 3.6.6. With a defaultPref of 1, after
> modifying network.proxy.type to 0 in the GUI/user profile, it remains at 0.
That's because Firefox default was changed. You need to select "Use system proxy settings" in Step 3 instead to reproduce the issue.
Comment 19 Masatoshi Kimura [:emk] 2011-11-10 14:55:01 PST
https://tbpl.mozilla.org/?tree=Try&rev=e42647d73b3c
Comment 20 Masatoshi Kimura [:emk] 2011-11-15 19:41:25 PST
Comment on attachment 573487 [details] [diff] [review]
patch

Dan looks to be inactive. roc, could you take a look?

This patch reverse the reading order of user prefs and AutoConfigs.

At present, user prefs will be lost in the follwing scenario.
1. An user starts Firefox.
2. Firefox will read the value of "network.proxy.type" from the AutoConfig.
3. The user changed the proxy settings to "Use system proxy settings".
4. The user closed Firefox.
5. "network.proxy.type" is written to prefs.js with the value 5 because
   it is different from the default value which the AutoConfig set.
6. The user started Firefox again.
7. Firefox will read the value of "network.proxy.type" from the prefs.js first,
   but it will be ignored and not considered as "user set" because 5 is the
   same value as default.
8. Firefox will read the value of "network.proxy.type" from the AutoConfig.
   The default value will be changed. The current value will also be changed
   because the value is not considered as "user set".
9. User settings is lost.

To wrap up, user pref values are compared against AutoConfig'ed values on save
while they are compared against initial default values on load. It doesn't look
consistent to me.

With this patch, the problem will be solved as follows:
1 to 6. Same as the above.
7. Firefox will read the value of "network.proxy.type" from the AutoConfig.
   The default value will be changed.
8. Firefox will read the value of "network.proxy.type" from the prefs.js.
   This time, it will be applied and considered as "user set" because 5 is
   different from the value from the AutoConfig.
9. User settings will be preserved.

Moreover, the notification topic name also suggests the current order is wrong.
https://mxr.mozilla.org/mozilla-central/source/modules/libpref/src/Preferences.cpp#404
>     rv = UseDefaultPrefFile();
>     UseUserPrefFile();
> 
>     NotifyServiceObservers(NS_PREFSERVICE_READ_TOPIC_ID);
https://mxr.mozilla.org/mozilla-central/source/modules/libpref/public/nsIPrefService.idl#182
> #define NS_PREFSERVICE_READ_TOPIC_ID "prefservice:before-read-userprefs"
It will be notified AFTER reading user prefs! This patch will fix the discrepancy.
Comment 21 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-11-15 20:49:04 PST
nsSystemPref::Observe calls GetBoolPref(sSysPrefString). That's going to start returning false always I guess. Is that OK?

What about nsReadConfig::readConfigFile calling GetDefaultBranch? will that do anything anymore?
Comment 22 Masatoshi Kimura [:emk] 2011-11-16 09:55:36 PST
Created attachment 574924 [details] [diff] [review]
patch v2

> nsSystemPref::Observe calls GetBoolPref(sSysPrefString). That's going to start returning false always I guess. Is that OK?
Good catch. I removed nsSystemPref because nsUnixSystemProxySettings already supported reading gconf settings. "Use system proxy settings" will do the job.
For system accecibility preference, I replaced it with nsIGConfService.

> What about nsReadConfig::readConfigFile calling GetDefaultBranch? will that do anything anymore?
No, it will no longer be required. Removed.
Comment 23 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-11-16 11:48:34 PST
Now you're removing config.use_system_prefs.accessibility, so users won't have the ability to override the system accessibility setting. Is that intentional? Do we need to check with someone that that's OK?

nsReadConfig::readConfigFile is still reading the general.config.filename, which won't return anything after your patch because no prefs are set up. That seems to be a problem.
Comment 24 Masatoshi Kimura [:emk] 2011-11-16 17:49:13 PST
> nsReadConfig::readConfigFile is still reading the general.config.filename, which won't return anything after your patch because no prefs are set up. That seems to be a problem.
I'm not sure I understand the problem.
general.config.filename is set in all.js or defaults/pref/*.js and is not supposed to be overridable by user prefs. I even tested it locally and it worked.
Comment 25 Masatoshi Kimura [:emk] 2011-11-16 17:55:23 PST
Comment on attachment 574924 [details] [diff] [review]
patch v2

> Now you're removing config.use_system_prefs.accessibility, so users won't have the ability to override the system accessibility setting. Is that intentional? Do we need to check with someone that that's OK?
Asking accesibility folks about that.
Comment 26 Masatoshi Kimura [:emk] 2011-11-16 18:15:46 PST
(In reply to Masatoshi Kimura [:emk] from comment #24)
> > nsReadConfig::readConfigFile is still reading the general.config.filename, which won't return anything after your patch because no prefs are set up. That seems to be a problem.
> I'm not sure I understand the problem.
> general.config.filename is set in all.js or defaults/pref/*.js and is not
> supposed to be overridable by user prefs. I even tested it locally and it
> worked.
In case you misunderstand the meaning of UseDefaultPrefFile(), it roughly corresponds to prefs.js, not system default pref files. UseUserPrefFile() corresponds to user.js. So not only the latter but also the former will read user settings contrary to the name.
Comment 27 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2011-11-16 19:53:56 PST
OK, thanks.

Is it really necessary to remove nsSystemPref? Isn't this disabling use of the proxy obtained via gconf?
Comment 28 alexander :surkov 2011-11-16 20:23:15 PST
Comment on attachment 574924 [details] [diff] [review]
patch v2

Trevor, you might be best to answer the questions since recently you touched this code.
Comment 29 alexander :surkov 2011-11-16 20:38:40 PST
This pref was introduced in bug 390761. But that bug doesn't say why it was introduced and I don't recall details. On the other hand this pref was settled down in the web like http://wiki.novell.com/index.php/Locking_Down_the_GNOME_Desktop and http://kb.mozillazine.org/Config.use_system_prefs. So I wouldn't remove it until you have a good reason to do this.
Comment 30 Ginn Chen 2011-11-17 20:25:46 PST
(In reply to alexander surkov from comment #29)
> This pref was introduced in bug 390761. But that bug doesn't say why it was
> introduced and I don't recall details. On the other hand this pref was
> settled down in the web like
> http://wiki.novell.com/index.php/Locking_Down_the_GNOME_Desktop and
> http://kb.mozillazine.org/Config.use_system_prefs. So I wouldn't remove it
> until you have a good reason to do this.

The pref was not introduced in Bug 390761.
In Bug 390761, we just copy it from widget/src/gtk2/nsWindow.cpp, because we need to query it in accessible/src/atk/nsAppRootAccessible.cpp.
We can not share the code between widget/ and accessible/ at that time.
Comment 31 Masatoshi Kimura [:emk] 2011-11-17 20:43:44 PST
The key is added in bug 202085 and bug 208763 which only explains about key name change. The behavior change is not explained at all. It was the reason I thought it would be OK changing the key name back.
Comment 32 Masatoshi Kimura [:emk] 2011-11-17 20:57:57 PST
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #27)
> Is it really necessary to remove nsSystemPref?
I'm not sure, but I can change the observed topic name to "profile-after-change" instead of dropping the module entirely.
> Isn't this disabling use of the proxy obtained via gconf?
As I explained in comment #22, "Use system proxy settings" (network.proxy.type=5) added a support for reading proxy settings from gconf. 
Even worse, the initialization order between AutoConfig and SystemPref is not defined as far as I know. So AutoConfig may fail to use the gconf proxy settings.
"Use system proxy settings" do not have this problem.
Therefore I don't think it is still useful for proxy settings. 
However it may be still required so that users can ovverride the system accesibility setting.
Comment 33 Masatoshi Kimura [:emk] 2011-11-19 07:26:51 PST
Created attachment 575669 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module
Comment 34 Masatoshi Kimura [:emk] 2011-11-19 07:27:47 PST
Created attachment 575670 [details] [diff] [review]
Part 2: Remove SystemPref module from the tree

It will not longer have an useful purpose.
Comment 35 Masatoshi Kimura [:emk] 2011-11-19 07:30:26 PST
Created attachment 575672 [details] [diff] [review]
Part 3: Reverse the reading order of user prefs and AutoConfig

I reverted a nsReadConfig::readConfigFile change. Although it is not required using GetDefaultPref anymore, it is harmless and it will give a clearer intention ("general.config.filename" is not user overridable).
Comment 36 Masatoshi Kimura [:emk] 2011-11-19 07:30:53 PST
https://tbpl.mozilla.org/?tree=Try&rev=b46057874895
Comment 37 Trevor Saunders (:tbsaunde) 2011-11-20 05:22:02 PST
Comment on attachment 575669 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module

> 
>+using mozilla::Preferences;

I hope you meant using mozilla;?

otherwise this looks fine to me modulo  some minor style stuff which will need to be touched again very soon in bug 693343
Comment 38 alexander :surkov 2011-11-24 22:08:03 PST
Comment on attachment 575669 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module

Review of attachment 575669 [details] [diff] [review]:
-----------------------------------------------------------------

r=me with Trevor's comment addressed
Comment 39 Masatoshi Kimura [:emk] 2011-11-25 10:48:40 PST
Created attachment 576969 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module. r=surkov.alexander

Thank you. Fixed using directive.
Comment 42 :Ms2ger 2011-11-28 13:31:57 PST
Comment on attachment 575670 [details] [diff] [review]
Part 2: Remove SystemPref module from the tree

>--- a/toolkit/library/nsStaticXULComponents.cpp
>+++ b/toolkit/library/nsStaticXULComponents.cpp
> #ifdef MOZ_ENABLE_GTK2
> #define SYSTEMPREF_MODULES \
>-    MODULE(nsSystemPrefModule) \
>     MODULE(nsAutoConfigModule)
> #else
> #define SYSTEMPREF_MODULES MODULE(nsAutoConfigModule)
> #endif

This could be simplified a bit, no?
Comment 43 Masatoshi Kimura [:emk] 2011-11-28 16:55:35 PST
Sure.
Comment 44 Masatoshi Kimura [:emk] 2011-11-28 16:57:40 PST
*** Bug 439695 has been marked as a duplicate of this bug. ***
Comment 45 Carl 2011-11-28 18:49:58 PST
It's been good to finally see all the recent productive activity for this bug report. Thanks for that, emk!

Now that this report has been marked resolved, I'm requesting that someone in-the-know summarize the fixes and changes implemented in layman's terms pertaining to how we end-users work with autoconfig files.

Also, which versions of Firefox and Thunderbird should we expect to benefit from these changes?
Comment 46 Masatoshi Kimura [:emk] 2011-11-28 19:40:32 PST
(In reply to Carl from comment #45)
> Now that this report has been marked resolved, I'm requesting that someone
> in-the-know summarize the fixes and changes implemented in layman's terms
> pertaining to how we end-users work with autoconfig files.
Now user set values will always be compared against defaultPref'ed values rather than factory default values. Therefore user set values will not be lost even if they happen to be the same as factory default values.

> Also, which versions of Firefox and Thunderbird should we expect to benefit
> from these changes?
Firefox 11 or later (see Target Milestone field).
Comment 47 Carl 2011-11-28 23:50:04 PST
As per comment #14, I found that in Firefox 7.0.1 the problem with defaultPref() had become much bigger. Rather than having problems only with user values being compared to the wrong thing, I found that all values of all preferences set with defaultPref() are simply ignored, regardless of whether the user also sets values. Does your fix correct this as well? I changed the priority to CRITICAL in comment #14 because this totally destroys our autoconfig functionality for everything but lockPref() calls.
Comment 48 Masatoshi Kimura [:emk] 2011-11-29 04:41:45 PST
(In reply to Carl from comment #47)
> As per comment #14, I found that in Firefox 7.0.1 the problem with
> defaultPref() had become much bigger. Rather than having problems only with
> user values being compared to the wrong thing, I found that all values of
> all preferences set with defaultPref() are simply ignored, regardless of
> whether the user also sets values. Does your fix correct this as well? I
> changed the priority to CRITICAL in comment #14 because this totally
> destroys our autoconfig functionality for everything but lockPref() calls.
I couldn't reproduce that problem even before the patch on my Win7 box. It may be a Linux specific problem. Anyway, please file it as a separate bug.
Comment 49 Masatoshi Kimura [:emk] 2012-01-10 17:02:37 PST
Comment on attachment 576969 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module. r=surkov.alexander

[Approval Request Comment]
Regression caused by (bug #): 
Not a regression, but the feature was broken from the start.
User impact if declined: 
defaultPref will be virtually useless. It will make the corporate deployment less flexible.
Testing completed (on m-c, etc.):
Yes (on m-c and m-a)
Risk to taking this patch (and alternatives if risky):
Some extensions may be affected if they depend on the order of the profile-after-change event.

Nominating this for the first ESR because AutoConfig is an important feature for enterprise deployment.
Comment 50 christian 2012-01-11 09:33:25 PST
Comment on attachment 576969 [details] [diff] [review]
Part 1: Allow overriding system accesibility settings without SystemPref module. r=surkov.alexander

[Triage Comment]
This doesn't meet the criteria for beta. That being said, it is a fairly self contained fix on Linux so the fallout would be minimal. Because Fx10 is the first ESR, let's try to shove this in. Approved for beta.

Yet another bug where ESR pressures us to make the wrong engineering choice, sigh.
Comment 51 Masatoshi Kimura [:emk] 2012-01-11 09:45:51 PST
Created attachment 587734 [details] [diff] [review]
Folded part 1 to 3 of this bug and patches of bug 705983 and ported to beta; a=clegnitto
Comment 52 Peeter Marvet 2012-01-11 10:12:01 PST
(In reply to Christian Legnitto [:LegNeato] from comment #50)
> it is a fairly self contained fix on Linux so the fallout would be minimal

sorry if I misunderstand you statement - but the bug was not limited to Linux, originally reported on Win, confirmed by me on Win with Firefox and Thunderbird...

(and thanks to everybody involved in fixing it, hopefully it gets into beta and release before the inevitable end-of-world)
Comment 53 Ed Morley [:emorley] 2012-02-05 11:25:41 PST
Post uplift this is now already fixed on beta, so removing checkin-needed + adjusting whiteboard accordingly.
Comment 54 Masatoshi Kimura [:emk] 2012-02-06 18:02:09 PST
I requested an approval because this is important for Enterprise users.
Is it possible to land this to ESR branch?
Comment 55 jaakko.luoto 2012-02-09 01:59:52 PST
As an enterprise administrator deploying Firefox and Thunderbird to our customers I was disappointed to find out that this fix didn't land to the ESR versions 10.0. I really hope that this lands to next versions in this ESR branch, Firefox 10.0.1 and Thunderbird 10.0.1 or whatever the next versions will be.
Comment 56 Masatoshi Kimura [:emk] 2012-02-09 03:13:00 PST
How can I request the ESR approval? I couldn't find a flag like "approval-esr10".
Comment 57 Alex Keybl [:akeybl] 2012-02-09 16:15:32 PST
(In reply to Masatoshi Kimura [:emk] from comment #56)
> How can I request the ESR approval? I couldn't find a flag like
> "approval-esr10".

We're working on finalizing the approval process, but this is the current draft (unimplemented): [1]

4-year-old bugs that aren't recent regressions or security fixes do not meet the criteria set forth in our ESR proposal [2], and we'll therefore not track for ESR10. It will, however, be available in ESR17. 

[1] https://wiki.mozilla.org/Release_Management/ESR_Landing_Process
[2] https://wiki.mozilla.org/Enterprise/Firefox/ExtendedSupport:Proposal#Assumptions
Comment 58 Mike Kaply [:mkaply] 2012-03-30 10:46:37 PDT
We believe this might have caused a very major regression in autoconfig (the very area this was trying to fix)

https://bugzilla.mozilla.org/show_bug.cgi?id=738043
Comment 59 kesselhut 2012-07-06 06:54:42 PDT
*** Bug 770860 has been marked as a duplicate of this bug. ***
Comment 60 Marco Katlun 2012-08-28 13:02:45 PDT
i haven't read all comments, but most of them, the bug is still not fixed. using a defaultPref is very helpful and essential to deploy it in an enterprise.

Setting this line in mozilla.cfg still doesn't work, in my case there isn't happening anything.
 defaultPref("browser.startup.homepage", "http://fek76");

pref and lockPref are working.

Could you please resolve this very old bug!

Tested with firefox 14 (de), 15 (de), 17.0a1 (en)
Comment 61 Mike Kaply [:mkaply] 2012-08-28 13:05:47 PDT
Setting a defaultPref on browser.startup.homepage has never worked like that. I'll do a blog post so people understand.

Try this:

defaultPref("browser.startup.homepage", "data:text/html,browser.startup.homepage=http://fek76");
Comment 62 Marco Katlun 2012-08-28 13:16:52 PDT
@Michael:
Thank you very much for your quick reply, it works perferctly. i've search for days to resolve this problem and haven't found anything about it.
Comment 63 jaakko.luoto 2012-08-29 00:25:14 PDT
mkaply, it would be great if you could also explain in your blog post why this "data:" part is needed and if there are any other preferences where it should be used.
Comment 64 Carl 2012-08-29 03:06:15 PDT
@Michael Kaply:

How about giving us a link to that blog posting?

Also, since this bug report had been ignored for years and then went spiralling off into the weeds, I have been using this line in my configuration (see comment #15 for setDefaultPref function):

  setDefaultPref("browser.startup.homepage", "http://1.2.3.4/");

This works perfectly and has done so for years. I realize it's not a call to defaultPref, Michael, but why am I getting away without that peculiar "data:" stuff?
Comment 65 Mike Kaply [:mkaply] 2012-08-29 06:01:28 PDT
Hopefully this post will answer your questions:

http://mike.kaply.com/2012/08/29/setting-the-default-firefox-homepage-with-autoconfig/
Comment 66 Stanislav GE 2014-02-25 03:58:14 PST
@Carl:

In what place do you put "setDefaultPref"? Doesn't work for me in a *.cfg file.
Comment 67 Stanislav GE 2014-02-25 04:18:21 PST
BTW, both pref and lockPref works perfect for "browser.startup.homepage" but defaultPref doesn't.
Comment 68 Carl 2014-02-25 18:33:20 PST
(In reply to Stanislav GE from comment #66)
> @Carl:
> 
> In what place do you put "setDefaultPref"? Doesn't work for me in a *.cfg
> file.

That function is one I wrote. Comment #15 shows the code for it that I include and thereafter use in my .cfg file. It was a knowingly flawed and desperate attempt to work around the Mozilla bugs.
Comment 69 Carl 2014-02-25 18:44:30 PST
(In reply to Stanislav GE from comment #67)
> BTW, both pref and lockPref works perfect for "browser.startup.homepage" but
> defaultPref doesn't.

We still use my setDefaultPref() function to set the homepage. But refer to comment #61 for the purportedly correct way to set the home page that does not require my function, which is where you may be going wrong.

Note You need to log in before you can comment on or make changes to this bug.