Closed Bug 272970 Opened 15 years ago Closed 12 years ago

autoconfig defaultpref doesn't work


(SeaMonkey :: Preferences, defect)

1.7 Branch
Not set


(Not tracked)



(Reporter: jehan.procaccia, Unassigned)


User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.3) Gecko/20040922

the defaultPref function define in
$MOZILLA_HOME/defaults/autoconfig/prefcalls.js doesn't work as expected for
setting the homepage.

I am using mozilla autoconfiguration as I decribed it in

I've tested in my autoconfig javascript this:

defaultPref("browser.startup.homepage", "");

Unfortunaltly I couldn't make it work -> set a default homepage without forcing
it ! it doesn't set it at all :-(
I've also tried to lockPref (which do successfully set the homepage):
lockPref("browser.startup.homepage", "");
then just after use unlockPref() to reanable modification -> no success :-(
I've also tried to use defaultpref and remove the
from the user's personnal prefs.js file, again no sucess :-( it wasn't set 

Is the defaultPref function working correclty at least on setting the homepage ?

I used it on a different preferences with success though !
//Privacy & Security
defaultPref("signon.rememberSignons", false);
here it works fine.


Reproducible: Always
Steps to Reproduce:
1. configure the autoconfig script with a defaultPref "directive" on the
homepage setting
2. start mozilla

Actual Results:  
The default home page doesn't shows up 

Expected Results:  
See the default homepage, and let the user change it . the LockPref function do
set and shows the homepage but as expected the user cannot use it.
note bug 264680 and bug 109932...

do other prefs work correctly with defaultPref?
Apparently defaultPref works fine for other prefs, at least I use it
successfully with that:
defaultPref("signon.rememberSignons", false);

 bug 264680 talks about an error generated, I don't have error, the problem is
that when I use defaultpref("browser.startup.homepage","");
when users start mozilla, there's no startup homepage at all :-(.

But perhaps I missuse that preference ?
I see the existance of 
("browser.startup.homepage_override", true);
("startup.homepage_override_url", "");
Should I defaultPref those too as well ? (I think I already  tested that before
with no success ...)

I just want to set a default homepage with autoconfiguration, and let users
change it if they wish .
The problem with the home page is that it's an indirect URL, so that it can be
easily localized. The best you can do is to point it to a readily available
.properties file which should then contain the actual homepage URL you want.
does that mean that is read after autoconfiguration pref
settings ?
The problem here is that I wanted to centralize preference setting in ONE place
with autoconfiguration .
I can start setting things in region.porperties but I really have a lack of
information about these settings ! Is there a place where is describe how
preferences are set ? which order ( 1) *.properties, 2) autoconfig with
general.config.filename , 3) users prefs ... others ??).
I discovered with you post, and found these doc: and

Please let us know what is the correct documentation that define officialy
preference settings , and is autoconfiguration a good method for the futur ...
Basically for a few prefs, of which the home page and throbber are just two, the
localizer gets to choose the default via the .properties file. The preference
setting just chooses which .properties file contains the localized URL. Thus if
you want to change the default you either have to change the .properties file
itself or point the preference at a new .properties file.
OK, I can start to customize .properties, but again, is this documented ? where ?
for exemple how do I "point the preference at a new .properties file" ?
Currently the preference (in all.js) reads
This means that the file in FR.jar (or whichever region you have installed) has
the actual value used as the default home page.
Now you need to create your own properties file, with the one line
Then just use autoconfig to set the preference to a URL to your properties file.
If you distribute the properties file with the browser then you can use
resource:/// or alternatively you can use a file URL such as
file://///smbserver/share/ or even a remote URL such as
http://webserver/ or ftp://ftpserver/
Version: unspecified → 1.7 Branch
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Does anyone think or care that it's reasonable that locked prefs get localized?
Sorry for CCing you by mistake :-[
Does anyone think or care that it's reasonable that locked prefs get localized?
I'm trying to follow the instructions in comment #7.  In all.js, I've put:

pref("general.config.obscure_value", 0); // for MCD .cfg files
pref("general.config.filename", "firefox.cfg");

and it does appear to read /usr/lib/firefox-, which has:

defaultPref("browser.startup.homepage", "resource:///");
defaultPref("general.useragent.contentlocale", "resource:///");



But I still get the system default.  What am I doing wrong?
Don't know why your defaultPref doesn't work, but I confirm that it doesn't for me neither .
 I finally resigned to set:
lockPref("browser.startup.homepage", "" );
in my /usr/lib/firefox-
So it does set the homepage to but then it's "mandatory", users cannot change it :-( , defaultPref, was, to my opinion , preferable to set a    homepage and still letting people the ability to chang it . but apparently it doesn't work :-( .

Anyway, I hope there's a larger comuntity using autoconfig in mozilla/thunderbird/firefox/seamonkey ... it's a very valuable feature for large scale enterprises, keep it running !
1.7 branch (Sm 1.0.x) is not supported anymore.

Is anyone still seeing this with a current build? If not, please resolve WORKSFORME.
No reply to comment #14 in 3 weeks -- resolving INCOMPLETE.

If you want to REOPEN, please paste the user-agent string (as shown after "Build Identifier" at the bottom of the about: page) of a current build experiencing the bug.
Closed: 12 years ago
Resolution: --- → INCOMPLETE
Can confirm that Firefox 3.6.6 still does this. Steps to reproduce:
1. Create a systemwide autoconfig/MCD .js file and include it by way of "general.config.filename" in defaults/pref/local-settings.js
2. Include defaultPref("browser.startup.homepage", "") or whatever page you like
3. Delete any existing FF profile and launch Firefox as a brand new user
Result: On the second run (after the homepage override stuff) you get a blank page, even though the preference is still "Show my home page." Clicking the home button gives you the generic Mozilla page, not the one you set. 
Expected: (or whatever) would be the homepage.

Further oddity: Even you manually set as the home page in the GUI, the field will remain blank and when you click the home button, you will get the Mozilla start page. Only if you set a page different from your defaultPref value in the GUI is it honored. (reminiscent of bug 451161)

In response to the question of whether other preferences work with defaultPref, yes. This is the only one I've seen that does anything like this.

Bug 449456 may be a duplicate.

Build identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100625 Firefox/3.6.6
You need to log in before you can comment on or make changes to this bug.