451161 - defaultPref overwrites user prefs

Status: RESOLVED FIXED

(Core :: Preferences: Backend, defect)

Description

[Carl]

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]

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]

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]

this seems to be larger problem, related to defaultPref implementation (and not limited to this particular pref), see bug 439695

Comment 4

[u88484]

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 [He/Him]]

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]

(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]

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 [He/Him]]

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]

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]

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]

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]

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]

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]

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]

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]]

Confirming.

Comment 17

[Masatoshi Kimura [:emk]]

Attachment: patch

This patch should fix the problem.

Comment 18

[Masatoshi Kimura [:emk]]

(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]]

https://tbpl.mozilla.org/?tree=Try&rev=e42647d73b3c

Comment 20

[Masatoshi Kimura [:emk]]

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) (email my personal email if necessary)]

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]]

Attachment: 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) (email my personal email if necessary)]

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]]

> 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]]

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]]

(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) (email my personal email if necessary)]

OK, thanks.

Is it really necessary to remove nsSystemPref? Isn't this disabling use of the proxy obtained via gconf?

Comment 28

[alexander :surkov (:asurkov)]

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 (:asurkov)]

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]

(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]]

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]]

(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]]

Attachment: Part 1: Allow overriding system accesibility settings without SystemPref module

Comment 34

[Masatoshi Kimura [:emk]]

Attachment: Part 2: Remove SystemPref module from the tree

It will not longer have an useful purpose.

Comment 35

[Masatoshi Kimura [:emk]]

Attachment: 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]]

https://tbpl.mozilla.org/?tree=Try&rev=b46057874895

Comment 37

[Trevor Saunders (:tbsaunde)]

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 (:asurkov)]

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]]

Attachment: Part 1: Allow overriding system accesibility settings without SystemPref module. r=surkov.alexander

Thank you. Fixed using directive.

Comment 40

[Dão Gottwald [:dao]]

http://hg.mozilla.org/integration/mozilla-inbound/rev/025b94f0f4cb
http://hg.mozilla.org/integration/mozilla-inbound/rev/62f14bed35a2
http://hg.mozilla.org/integration/mozilla-inbound/rev/aa093660a497

Comment 41

[Marco Bonardo [:mak]]

https://hg.mozilla.org/mozilla-central/rev/025b94f0f4cb
https://hg.mozilla.org/mozilla-central/rev/62f14bed35a2
https://hg.mozilla.org/mozilla-central/rev/aa093660a497

Comment 42

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

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]]

Sure.

Comment 45

[Carl]

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]]

(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]

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]]

(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]]

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

[LegNeato]

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]]

Attachment: Folded part 1 to 3 of this bug and patches of bug 705983 and ported to beta; a=clegnitto

Comment 52

[Peeter Marvet]

(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]]

Post uplift this is now already fixed on beta, so removing checkin-needed + adjusting whiteboard accordingly.

Comment 54

[Masatoshi Kimura [:emk]]

I requested an approval because this is important for Enterprise users.
Is it possible to land this to ESR branch?

Comment 55

[jaakko.luoto]

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]]

How can I request the ESR approval? I couldn't find a flag like "approval-esr10".

Comment 57

[Alex Keybl [:akeybl]]

(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]]

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 60

[Marco Katlun]

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]]

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]

@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]

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]

@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]]

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]

@Carl:

In what place do you put "setDefaultPref"? Doesn't work for me in a *.cfg file.

Comment 67

[Stanislav GE]

BTW, both pref and lockPref works perfect for "browser.startup.homepage" but defaultPref doesn't.

Comment 68

[Carl]

(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]

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