Autoconfig not working

iirc, chris has been working on documenting the preferences. she might be good
reference here.

a gazillion developers touch the prefs --i'm cc'ing a couple here (brian and
seth) who might have some comments...

-->cwozniak.

>What is a preference?
Preferences are not JavaScript variables. Preferences are stored in a (more or
less) human readable form which is parsed by the JavaScript parser. Some day we
would like to remove this dependency because JavaScript is overkill for this
need (and opens us up to security issues.)

>Prefernce load order: That should be PreferEnce ;)
Again preferences are not JavaScript variables, but they will be resolved in
favor of the last entry read... unless locking (AutoConfig) is involved. Let's
not go there just now...

I don't really understand item 3 "Use default, hard-coded value for prefs".
Assuming that a value exists in *any* preference file, it will override any
value set in the code.

>Because prefs.js is loaded last... changes to a profile should made to the
prefs.js.
prefs.js is a generated file. Users should not be messing with it unless they
are absolutely certain of what they are doing.

"user.js" is actually the last file loaded. This file is only read in and never
written out, and is where the user should be installing their own personal
preferences (the default homepage is a common one). This way user can create a
new profile, drag their "user.js" file into it, and immediately be in a familiar
environment. The other advantage is that you can have comments or commented out
preferences in user.js and they won't be purged the next time the file is
written out.

>Modifying preference files:
Again, users shouldn't really be mucking about in prefs.js.

>Systems administrators can modify <mozilla>/defaults/prefs/
System Administrators would generally use AutoConfig to do this sort of thing
(through CCK). Hacking individual installations is tedious.

>Care should be taken in modifying values in the "default/prefs" files...
If you (and here you means a developer) changes a value in "default/prefs", that
becomes the new default. If that value is set to the same value that is in
prefs.js, then yes, the value will be removed from prefs.js the next time it is
saved. If, however, you change the value from "0" to "3", and prefs.js has a
user value of "1", the user value will remain in effect because it is *not* the
same as the default value.

Hi I'm pulling together the Preference Reference that will help NCADM users do
customizations that they cannot do using the NCADM tool (rtm around 8/30). The
NCADM tool is a wizard that includes an Advanced Preferences page. Most of the
customizations that a majority of our customers would want to do can be
accomplished either via the wizard or the Advanced Preference Editor. CCK is a
scaled back version of NCADM (or NCADM is an enhanced version of CCK). CCK is
available for download; NCADM will be available for sale.

Also, there are appendixes in the NCADM guide (still in process, almost ready
for review) that deal with the preference architecture and remote administration.

That said, it would be good at some point to sync up the commercial doc with the
open source doc so that we are sending a uniform message.

Let's put our heads together.
Chris

I am not sure this document doesnt have anything we already have in our current
preferences documentation. However if you guys/gals could get together with
Christine and put out an overall document that would be great. If you disagree
please let me know.

So far, the only real way I've been able to find any documentation on Mozilla's
hidden preferences are by doing searches on Google or wading through the
(incompletely documented) js files themselves. As a power user, many of the
undocumented options that I have managed to dig up information on have been of
interest to me. It would be nice if I could find these all documented in one
place, either on the web or in Mozilla's help system.

keyser:

Where's the current documentation? I would have never written this if someone
had given me the info I wanted, I had to figure all this out myself and use it
to help answer a variety of networking questions I was being asked.

Believe me, I got a day job, and plenty of bugs to go with it.

I'd be willing to make a long-term commitment to document network-related prefs.

Is there a master document that lists prefs one by one?

*** This bug has been marked as a duplicate of 158384 ***

*** Bug 178685 has been marked as a duplicate of this bug. ***

Is this bug still valid? We already have
http://mozilla.org/start/1.0/faq/general.html#1.5

btw, the packetgram.com url does not work; reporter, can you post
the doc as an attachment?

and is this bug a request for Help file content, or a request for
mozilla.org content?

The packetgram URL does work for me.

I did not understand the relationship of user.js and prefs.js until now.

I'll make a draft that has the updated changes, and attach it here, then delete
the file from the packetgram system.

I think this bug is still valid.
The prefs documentation mentioned
(http://mozilla.org/start/1.0/faq/general.html#1.5) was nigh impossible for me
to find. I searched the help system for prefs.js and nothing came up.
Searching mozilla brought me here, which brought me to it.
Plus, it's quite *nix-specific. (e.g. Customizing Mozilla)
(And I still can't find the pref for having MozillaMail check all IMAP folders
for new messages. Scanning about:config for it now..)

Matthew: take a look at the document in the URL field, and tell me if it is
missing anything you wanted to know.

brian: I know you are probably gone, but I finally sat down today and made a lot
of the helpful corrections you provided.

The URL is still the same.

I need to re-read your comments again, do a final re-write+spellcheck, then I'll
be punting this document into mozilla.

I'm going to remove the file and pref specific info from this file, and post it
here.

I've reopened the dupe for the per-file, per pref info.

REOPEN: this bug wanted more specific info on each pref.

I don't know about the rest of the browser, but I'm going to be doing this for
neworking prefs.

Ben, I don't see how http://bugzilla.mozilla.org/show_bug.cgi?id=158384 differs.
Seems that 158384 should cover all prefs, so this bug is still a dupe of that.

(sleep and caffeine shortage over here..)

Writing about how the prefs mechanism works is significantly different than
writing about how each pref affects the browser behavior. That is actually how
engineering and QA divide the pref bugs.

I think that we've got the prefs back-end material documented well in that bug,
so I'd like to separate the per file, per pref issues here.

Putting them all in one bug/document is just too messy. If you look at my
current draft document, you can see some (soon to be removed) comments about
specific prefs and pref files.

Done.

cvs -z9 commit -m "added "A Brief Gude to Preferences"" index.html
briefprefs.html (in directory
C:\HOME\mozilla-org\html\catalog\end-user\customizing\)
Checking in index.html;
/cvsroot/mozilla-org/html/catalog/end-user/customizing/index.html,v <-- index.html
new revision: 1.6; previous revision: 1.5
done
RCS file: /cvsroot/mozilla-org/html/catalog/end-user/customizing/briefprefs.html,v
done
Checking in briefprefs.html;
/cvsroot/mozilla-org/html/catalog/end-user/customizing/briefprefs.html,v <--
briefprefs.html
initial revision: 1.1

This is only about the preferences system, not the actual prefs themselves,
right? Adding "generic" to the summary, assuming I am right. I thought this bug
was about documenting the meaning of the individual prefs.

Perhaps the documentation should be generated from whatever comes out of bug
195845, so that there aren't two independent places documenting the same thing.

If anything, then the other way around. Bug 17199 would also need very detailed
information about each pref, including documentation about possible values (for
enums).

Not really. That's the funny thing, I wrote the doc, I wrote the bug, I put the
URL in the bug. Nobody reads the doc. There used to be some pref-specific
comments, but that was because the document lived on packetgram, which was a
network-troubleshooting web site that I run.

Whatever. Ben, if you can review this doc, esp checking to see if I got bnesse's
feedback correct, I'll take ownership of this bug, and then mark it fixed.

If this document just does not do what it should, comment away.

Both of those bugs sound like features to the prefs system, but separately, I
think the behavior needs to be well documented. Some of these prefs are very
complicated, and a full write-up should be put somewhere.

I've decided to create a guide to networking preferences, for my own sanity, if
not for anyone else' benefit, I'm going to make a list of networking preferences
w/ links to any useful information I can readily find. see bug

Eventually, I'll have time to write coherently about each pref. This might occur
i n one doc, although my thinking is that the prefs are best explained in
individual write-ups of the modules they affect.

I think we need a similar document for all prefs, that lives some place central.

Created an attachment (id=121869)
briefprefs.html

clarify things a little bit and add some details on the preference system.
to-do:
- example of how to change preferences by code at run-time
- naming conventions (bug 58816)
- pref-by-pref reference

Ben, are you the module owner of pref lib?

Created an attachment (id=121908)
briefprefs.html (+ pref design spec)

Nope. I wrote that document because I couldn't live without it, and needed it as
the basis of:

http://www.mozilla.org/quality/networking/docs/netprefs.html

If you sensed the focused "get in, say some stuff, and get out" style of this
document, now you know why. My current job is to test just networking features.

You've done a great job of improving the documentation. I have not reviewed the
changes in detail, but I liked what I saw. Unfortunately, I won't be able to do
a through reading anytime soon. I also am not the ideal person to review a
document like this.

If you think this is ready to go, check it in, and we'll take changes from
people interactively. I've found that it is very hard to get people to review
changes before you make them.

A comment about the section "Naming conventions" in attachement 121908.
It uses several "capability.policy.default.foo" as example on how to name
preferences. In fact, those preferences are named as required by the object
names in class info and the method names in IDL. Of course, those have a naming
convention, but this is not a preference naming convention.
This suggests that caps prefs really have a option on how to name the preference,
which doesn't exist.

Created an attachment (id=121964)
briefprefs.html

Axel, those preferences exist before any naming rule exist
What I am trying to do is to look at how existing preferences
are named, and then infer from them a naming scheme that is
compatible with current ones. The scheme needs to be useful
but not accurate as far as the history of naming is concerned.

in this version I have added many more detail on how preferences
are handled and many contextual links to LXR. I've also added
some code examples.

Created an attachment (id=122086)
600+ preference names, descriptions and valid options

This may prove helpful in creating comprehensive documentation for Mozilla
preferences.

As a further explanation to comment #22:

I currently run a project over at preferential.mozdev.org which aims to:
(1) provide a consistent GUI interface to all Mozilla prefs (this is now subwhat
superceded by about:config) and, more importantly,
(2) document all Mozilla preferences

I don't want to duplicate effort here, so if there's any way I can contribute to
the Preferences documentation effort, I'd love to help.

I have attached my project's source preferences file (which I later convert into
two RDF files using a Perl script). It doesn't document all preferences, but
has so far recorded about 600 preferences and their options. I'm happy to
massage this into a suitable format for someone if there is interest.

See bug 198252 for anything network releated.

Daniel: this document is great! Lots of things I've wanted to know, but never
would have been able to cover myself.

a couple comments:

"arises" could be "arising"
"In Netscape product" should be "In Netscape products"
"On application exit, all user-set value" should be "values"
(See more information) has the HREF extending over the last ")"

The paragraph that is struck out about developers changing prefs is good info,
but I think it should be moved into the same area you had your sample code,
"Accessing preferences programmatically"

I've read up to the namespace section, I'll try to digest the rest when I can.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021207 Phoenix/0.5

The setting autoadmin.global_config_url available in Netscape v4.x doesn't
appear to have made it into any of the mozilla series of browsers. This was a
VERY useful option for those of us who manage a large number of "locked down"
systems such as in schools. The purpose of this setting was to allow an
administrator to put a config file on a web server and automatically change or
update browser settings for all of the systems which use it.

I've written an article on locking down Mozilla/Phoenix and would really like to
be able to include instructions for maintaining a central configuration as well.
 The article can be found at
http://archives.seul.org/seul/edu/Jan-2003/msg00049.html

Reproducible: Always

Steps to Reproduce:
1. Set the value for autoadmin.global_config_url in the browser configuration file.
2. Make sure a valid config file is available at the URL used in #1
3. Exit and restart Mozilla

Actual Results:
Error complaining of unknown option autoadmin.global_config_url. No change in
browser configuration.

Expected Results:
Browser should have taken on some of the lockPref settings in the online config
file.

I have had several people respond to my article asking about this feature as
well. For some, this is blocking adoption of Mozilla or Phoenix in their schools.

some changes checked in

I've rewritten the doc for users & administrators. reference to developers
removed (will be moved to a separate doc). The doc will be temporary (should
have been in /docs instead of catalog); I'll find a more appropriate place once
I finished my other docs on user profile.

Created an attachment (id=125156)
preference reference for developers

no idea why I bothered it, but here we go, relieving myself of this doc

Created an attachment (id=125210)
Mozilla Preferences Manual (work-in-progress)

<PROFILE>/*.js & <browser>/defaults/pref/* have been taken care of by bug 158384
(just need to find an appropriate place for the doc).
-> me , and making Brant my editor :-)

(oh, btw, red is for hidden pref and blue for non-hidden prefs. black's for
update-later ;-p )

oops

Daniel Wang, that's great, thanks, esp. that you have text for each possible
value (where it makes sense), e.g. editor.encode_entity. The more structure the
better :).

In case it's of any use for you, I tried to invent an XML data format for the
prefs documentation. It's a draft and probably wrong or lacking at places, but
maybe you can use it or some of its ideas.
<http://www.bucksch.com/1/projects/mozilla/17199/>

Created an attachment (id=125500)
~70 prefs and counting

I think I've config & AutoConfig figured out, so now I can fix bug 158384 for
end users easy.

what do you guys think about the following doc structure:

moz-org/docs/end-user/ [sigh, should be moz-org/end-user/]
  customizing/
    theme?
    command-line-args.html [move from moz-org/docs]
  pref/ [or config/? or just customizing/?]
    index.html
    pref.html [current briefprefs.html file]
    config.html [info on .cfg and .jsc config files]
    seamonkey/ [for Mozilla app suite]
      index.html [index to complete pref manual]
      hidden.html [reduced version, contains only useful prefs]
    browser/ [for future standalone browser]
    mail/ [for future standalone mail]
  profile/

> doc structure:

Move Pref/ and customizing/ under profile/?

Ben - in 'What is a preference?' I believe you have a type in spelling of
prefs.js as perfs.js - only a small thing but a potential trap for a newbie.

Created an attachment (id=129685)
~160 prefs and counting

printing prefs done

This is an essential feature required for large base installation. Anybody
within the Mozilla group want to comment on the state of this bug/feature
enhancement?

The pref is present, see my attachment in bug 178685. But it must be set in a
.cfg file.

Need doc to expand on bug 158384

We have delayed this long enough -> P1

Hi,
Even though preference is there, I do not think it's working. I have modified
all.js and added

pref("general.config.filename", "vendor.cfg");
pref("general.config.vendor", "vendor");
pref("autoadmin.global_config_url","http://myserver/autoconfig.jsc");

This caused Mozilla (1.5) to hit the webserver and download the configuration
file, which looked like :

Content-type: application/x-javascript-config

with (PrefConfig) {
lockPref("browser.startup.homepage", "http://www.google.com");
lockPref("browser.startup.homepage_override", true);
lockPref("general.config.vendor", "vendor");
lockPref("startup.homepage_override_url", "http://www.google.com");
} // End with prefconfig

No home page change is observed.

Either there is something missing in the documentation, as to how this feature
should be used, or it is simply broken. Lack of this feature is a show
stopper for a large scale deployment.

I agree.. this still is not functional. It does indeed read the config file
from the web server, however, it doesn't seem to use any of the options set there.

This is my .js file from the web server:
# Mozilla User Preferences
lockPref("browser.startup.homepage", "http://ourserver/");
lockPref("network.image.imageBehavior", 0);
lockPref("network.proxy.autoconfig_url", "http://ourserver/proxy/srhigh.proxy");
lockPref("network.proxy.type", 2);
... many more lockPrefs

No change to home page or proxy settings and no preferences were locked.
No errors were generaged either. Tested on Linux and Windows v0.6.1 and v0.7.0.

This is preventing us from deploying to 2000+ systems.

autoadmin.global_config_url must be in vendor.cfg (not all.js) to take effect.
The .cfg file must be 13-bit shift encoded. The script on Alain Knaff's site is
not working. I was told in bug 222973 that the script needs Perl 5.8.0+, maybe
it will work for you.

It was in the .cfg file. The .cfg file was 13-bit shift encoded, and the .cfg
file was specified in all.js. In fact, the browser actually retrieves the
remote config from the web site. The retrieved javascript file doesn't have any
affect on the browser's configuration.

According to info at
http://bugzilla.mozilla.org/attachment.cgi?id=125500&action=view#00052 the file
on the web server is plain javascript. If this is not the case, some
documenatation somewhere needs to say this. Once we have a working solution,
I'll update my instructions at
http://archives.seul.org/seul/edu/Jan-2003/msg00049.html to reflect the correct
way to use the remote config URL.

At least in Firebird 0.6.1 and 0.7 this still does not appear to be functional.

I think I solved the mystery. The problem seems to be with (PrefConfig)
directive.

I have simplified my vendor.cfg, and autoconfig.jsc (which is a CGI output in
our environment) and it seems to be working now.
I'd appreciate if people can try this and report the results.

----- vendor.jsc --- below should be hashed using moz-byteshift.pl and saved
as vendor.cfg under mozilla home------------
lockPref("general.config.vendor", "vendor");
lockPref("autoadmin.global_config_url","http://server/mcontrol/mconfig.cgi");
lockPref("autoadmin.append_emailaddr",true);
-------------
------ all.js should have the following : ------
pref("general.config.filename", "vendor.cfg");
pref("general.config.vendor", "vendor");
---------------------------------------------------

---------- Output of the mconfig.cgi should generate something like this ------
Content-type: application/x-javascript-config

defaultPref("browser.search.defaultengine", "engine://C%3A%5CProgram%20Files%
5Cmozilla%5Cbin%5Csearchplugins%5Cgoogle.src");
defaultPref("browser.search.opensidebarsearchpanel", false);
lockPref("browser.startup.homepage", "http://www.google.com");
lockPref("startup.homepage_override_url", "http://www.google.com");
lockPref("browser.startup.homepage_override", true);
lockPref("editor.author", "Your Name");
------------------------------------------

Whatever you choose as the vendor, filename should agree with that. (e.g.: x,
x.cfg )

Right now I am able to change homepages etc by pushing the config from the
server. This also works with FireBird. Haven't tested thunderbird yet.

After reading comment 8 From Gokhan Topalhan , I did made it work on linux :-)
I don't know what is the vendor.cfg file ? where it should be and how to tell
mozilla to read it, so I kept playing with all.js as follows:

Create the autoamdin.global_config_url file

$ cat mci-mozilla-web-tux.js
lockPref("general.config.vendor", "mci-mozilla-web-tux");
lockPref("autoadmin.global_config_url","http://corbeau.int-evry.fr/cgi-bin/mci-mozilla-glob-prefs-tux.cgi");
lockPref("autoadmin.append_emailaddr",true);

Encode it:

$ ./moz-byteshift.pl -s 13 < mci-mozilla-web-tux.js > mci-mozilla-web-tux.cfg

move cfg file to mozilla-home:

$ cp mci-mozilla-web-tux.cfg /usr/lib/mozilla-1.4/

Add the 2 following lines to all.js

$ tail -2 /usr/lib/mozilla-1.4/defaults/pref/all.js
pref("general.config.filename", "mci-mozilla-web-tux.cfg");
pref("general.config.vendor", "mci-mozilla-web-tux");

and here's my perl cgi script on the web server:

$ cat /var/www/cgi-bin/mci-mozilla-glob-prefs-tux.cgi
#!/usr/bin/perl -w

print ("Content-type: application/x-javascript-config\n\n");
$page = <<"EOP";
try {
  var env_user = getenv("USER");
  var env_home = getenv("HOME");
  var env_mozdebug= getenv("MOZILLA_DEBUG");
function processLDAPValues (values) {
    var uid = getLDAPValue ( values , "uid" );
    var cn = getLDAPValue ( values , "cn" );
    var mail = getLDAPValue ( values , "mail" );
lockPref("mail.server.server1.name", mail );
lockPref("mail.identity.id1.fullName", cn);
lockPref("mail.identity.id1.useremail", mail);

if (env_mozdebug) {
        displayError("debug mozilla.cfg v2.8", "mail:" + mail + "uid:" + uid +
"cn" + cn + "user:" + env_user );
        }

  }
//BROWSER
lockPref("browser.startup.homepage", "http://www.int-evry.fr/mci/user/");
lockPref("browser.startup.homepage_override", true);
lockPref("general.config.vendor", "mci-mozilla-web-tux");
lockPref("startup.homepage_override_url", "http://www.int-evry.fr/mci/user/");
lockPref("browser.cache.disk.capacity", 0);
lockPref("network.cookie.cookieBehavior", 0);
lockPref("network.proxy.autoconfig_url",
"http://www.int-evry.fr/local/config.proxy");
lockPref("network.proxy.type", 2);

//Account
lockPref("mail.account.account1.identities", "id1");
lockPref("mail.account.account1.server", "server1");
lockPref("mail.account.account2.server", "server2");
lockPref("mail.account.account3.server", "server3");
lockPref("mail.accountmanager.accounts", "account1,account2,account3");
lockPref("mail.accountmanager.defaultaccount", "account1");

//imap
lockPref("mail.server.server1.hostname", "imap-int.int-evry.fr");
lockPref("mail.server.server1.type", "imap");
lockPref("mail.server.server1.login_at_startup", true);
lockPref("mail.identity.id1.draft_folder", "imap://" + env_user +
"@imap-int.int-evry.fr/Drafts");
lockPref("mail.identity.id1.drafts_folder_picker_mode", "0");
lockPref("mail.identity.id1.fcc_folder", "imap://" + env_user +
"@imap-int.int-evry.fr/Sent");
lockPref("mail.identity.id1.fcc_folder_picker_mode", "0");
lockPref("mail.identity.id1.stationery_folder", "imap://" + env_user +
"@imap-int.int-evry.fr/Templates");
lockPref("mail.identity.id1.tmpl_folder_picker_mode", "0");
lockPref("mail.id...

-> WFM :-)

It works as advertised (for Linux AND Windows.) I found the problem I was
having was that I had left some comments in. Apparently comments starting with
# will cause Mozilla to abandon the rest of the config file.

If you must use comments, use the C style of comment. ie:
/* Comment */
or
/* Multi
    line
    comment
*/

Also, I was able to completely leave out the general.config.vendor and
autoadmin.append_emailaddr settings. No rights changes to the install dir or
subdirs were required.

The config online can be a cgi/php,etc. script or just a simple config file. My
preference is to use a cgi/php so laptop users can have a different config when
using their system while off site.

> It works as advertised (for Linux AND Windows.) I found the problem I was
> having was that I had left some comments in. Apparently comments starting
> with # will cause Mozilla to abandon the rest of the config file.

A preference file is a JavaScript file. If there is a syntax error, than the
application will abort reading it and none of the preferences defined take
effect. With exception of user.js, however, the first line is never read. The
first line is usually non-parseable and begins with # (not a valid js syntax).
This prevents inadvertant loading of preference files from the outside.

for more info, see bug 178685

Created an attachment (id=134853)
profile.zip (~200 prefs)

Ok, i've tested on mozilla 1.4 and 1.5 on windows and linux and it works fine.
I've explained everything in my updated doc:
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html
cf particularly chapter 5 dedicated to mozilla !. I hope this could be a
reference to all who wants to use that unvaluable feature (autoconfig !) of
mozilla .

However I'am still questionning on how to make this service reliable (cf chapter
8) that is to say, how to move to a different web server if one is down, same
question for the ldap server !
I also don't know why alert() javascript function don't work, is was very
usefull in netscape to use it to popup messages as mozilla start (debug/info
...), I use displayError now but it's not very clean ...

Thanks to all for your help.

Jehan Procaccia, you need to change 5.8 to reflect what I said in comment 21.

Preference files and config files are special js files with limited scopes. They
can only call the get/set pref/env methods and have no access to other objects
(need to investigate what exactly are allowed). alert() is a method of the
Window object.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

With Firebird or Mozilla, it is possible to use
pref("general.config.filename", "ect.cfg");
pref("general.config.vendor", "ect");

preferences in all.js and make the client query a web server to download
preferences. Support for this feature does not exist in Thunderbird. I am sure

Reproducible: Always

Steps to Reproduce:
1. Read
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html
and set up a mission control server as described in
http://bugzilla.mozilla.org/show_bug.cgi?id=206294
2. Launch thunderbird
3. Observe web server logs to see a hit
Actual Results:
No hits to the mission control servers coming from thunderbird client

Expected Results:
Thunderbird should contact the web server and download the configuration and
apply them (lock some settings etc.), like Mozilla or Firebird does. However, it
looks like it doesn't do that.

When I compile thunderbird on Linux with just export MOZ_THUNDERBIRD=1
mk_add_options MOZ_THUNDERBIRD=1 set in the .mozconfig it actually works but of
course it's not thunderbird anymore.

I'm curious, are you deploying thunderbird in an enterprise space that relies on
MCD? We at the Mozilla Foundation would probably be interested in talking to you
if so.

this should work fine if you build the pref extension, e.g., in mozconfig.txt,
add the following line:

ac_add_options --enable-extensions=wallet,pref

However, not knowing that anyone was using the MCD stuff, I've changed it so
that the returned js file is unobscured...

I just realised that an arbitariliy named file put on
/usr/lib/mozilla-1.2.1/defaults/pref will be read, too. That's for
mozilla-1.2.1, Red Hat release. If this is standard behaviour, it ought to be
documented.

Also, I'm trying to include default mail account settings in my site config, but
can't figure out how. The problem is setting
   mail.server.<server name>.userName
This is of course user specific, but the value is always identical to the
Unix/Linux login name, so it ought to be possible to set up the value in all.js
or similar. Oh, and
   mail.identity.<id>.useremail
is needed as well, but that can be derived directly from the above info.

maybe I could use the autoConfig method or .cfg file along with getenv(), but I
haven't been able to get those methods to work yet (and getenv() is not
available in from .js files.)

New problem :-(
Don't know if it's a bug or a misconfiguration ... however I use this "channel"
to join you all (let me know if there's a better place to post that).

I realized that my ldap based lockPref gets a white space in front of every
variables fetches from ldap. I didn't noticed that before because it doesn't
matter for standard smtp mail, however our mailling list server (sympa)
complains about a bad address when the email address contains a white space;
here's the symptoms:
Return-Path: <" <email address hidden>>
So mail is rejected :-(
indeed in users prefs.js there's:
user_pref("mail.identity.id1.useremail", " <email address hidden>");
                                          ^
Why I get this white space ?

Recall how I lock the useremail pref:

try {
// Get Shell env varirables
  var env_user = getenv("USER");
  var env_home = getenv("HOME");
  var env_mozdebug= getenv("MOZILLA_DEBUG");
// Call ldap
function processLDAPValues (values) {
    var ldapuid = getLDAPValue ( values ,"uid" );
    var ldapcn = getLDAPValue ( values ,"cn" );
    var ldapmail = getLDAPValue ( values ,"mail" );
//Debug for me ... (there was alert() before, not availaible anymore :-( )
if (env_mozdebug) {
        displayError("debug 1 mozilla.cfg v2.22", "\nmail:" + ldapmail +
"\nuid:" +ldapuid + "\ncn" +ldapcn + "\nuser:" + env_user );
        }
lockPref("mail.server.server1.name",mail);
lockPref("mail.identity.id1.fullName",cn);
defaultPref("mail.identity.id1.useremail",mail);

//Call to ldap to get user's attribute .
getLDAPAttributes ( "ldap2.int-evry.fr", "ou=people,dc=int-evry,dc=fr",
"uid="+env_user , "uid,cn,mail" );

The problem in that either mail, cn or uid, gets a white space in front ,
env_user which doesn't need the any of the getLDAP* function call works fine (no
white space)

How can I solve that ? search why a white space is added, or keep on with it and
find a javascript function that removes it , kind of chop() in perl, i don't
know javascript, I've also been told that all this autoconfig runs in a very
closed scope, not all of the javascript object/library is available :-(
How can I debug javascripts calls, variable better than using the displayError()
call ?

help would be grealty appreciated, I've hundreds of mozilla mail user autoconfig
running here ...

Thanks.

OK, found a workaround, not clean but working, I added the following line to
/usr/lib/mozilla-1.4.1/defaults/autoconfig/prefcalls.js in the getLDAPValue
function:

start_pos +=1;

so now it removes the preblematic "white space" in front of my ldap fetched
variables.

Here's the whole function debuged by me using displayError function (don't know
a better way to debug :-( )

function getLDAPValue(str, key) {

    try {
        if (str == null || key == null)
            return null;

        var search_key = "\n" + key + "=";

        displayError("Jehan getLDAPValue:\nsearch_key:"+search_key+"\nstr"+str);

        var start_pos = str.indexOf(search_key);
        if (start_pos == -1)
            return null;

        start_pos += search_key.length;
//start
        start_pos +=1;
//end
        var end_pos = str.indexOf("\n", start_pos);
        if (end_pos == -1)
            end_pos = str.length;

        var attrib = str.substring(start_pos, end_pos);
        displayError("Jehan
getLDAPValue:\nattrib:"+attrib+"\nstart_pos:"+start_pos+"\nend_pos:"+end_pos);

        return str.substring(start_pos, end_pos);

    }
    catch(e) {
        displayError("getLDAPValue", e);
    }
}

Is this a bug ? let me know ...

Will this bug be fixed?

Don't even know if it's a bug, at least the workaround I presented above worked
for me (others ? let me know ...), but if it is a bug, should I open a new bug
report ?

I would open a new bug report. This one is really about URL autoconfig and not
LDAP config issues. Also, this bug has been effectively closed with a
"WORKSFORME" status.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.4) Gecko/20031027
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr; rv:1.4) Gecko/20031027

I use autoconfig, which I documented on
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html
and opened a "bug" ID 222973 about lack of doc, I realized that my ldap based
lockPref gets a white space in front of every
variables fetches from ldap.
here's the symptoms:
Return-Path: <" <email address hidden>>
So mail is rejected :-(
indeed in users prefs.js there's:
user_pref("mail.identity.id1.useremail", " <email address hidden>");

Reproducible: Always

Steps to Reproduce:
1.use autoconfig with variables fetched from ldap, cf
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html#htoc10
2.typical javascript code in my autoconfig file: var ldapmail = getLDAPValue (
values ,"mail" );
3.

Actual Results:
here's the reulted user preference:
user_pref("mail.identity.id1.useremail", " <email address hidden>");
note the unwanted "white space" in from of the email address

Expected Results:
not inserted the white space:
user_pref("mail.identity.id1.useremail", "<email address hidden>");

I found a workaround, cf bug 206294: , incrementing by 1 start_pos in function
getLDAPValue from autoconfig/preffcalls.js, see below bettwen //start //end:

function getLDAPValue(str, key) {

    try {
        if (str == null || key == null)
            return null;

        var search_key = "\n" + key + "=";

        displayError("Jehan getLDAPValue:\nsearch_key:"+search_key+"\nstr"+str);

        var start_pos = str.indexOf(search_key);
        if (start_pos == -1)
            return null;

        start_pos += search_key.length;
//start
        start_pos +=1;
//end
        var end_pos = str.indexOf("\n", start_pos);
        if (end_pos == -1)
            end_pos = str.length;

        var attrib = str.substring(start_pos, end_pos);
        displayError("Jehan
getLDAPValue:\nattrib:"+attrib+"\nstart_pos:"+start_pos+"\nend_pos:"+end_pos);

        return str.substring(start_pos, end_pos);

    }
    catch(e) {
        displayError("getLDAPValue", e);
    }
}

OK, I opened a new bug report :
http://bugzilla.mozilla.org/show_bug.cgi?id=229271

Richard: I made a quick scan and fixed one "perf" mispelling. Thanks for the
feedback!

-> ownership to me.
I've updated the document also to remove Netscape references.

I think this document (mostly due to Daniel), is really in good shape now, so we
should start talking to other people that have less updated prefs docs, and have
them link to us.

Here's a quick list I found:

http://www.mozilla.org/start/1.4/faq/general.html#hidden-pref (no link to us).
http://www.mozilla.org/unix/customizing.html#prefs
http://www.mozilla.org/support/

I'am glad you finally made it work

we are about to form a community that use mozilla autoconfig, and hopefully
we'll be enough to assure that developpers keeps make this unvaluaible feature
work, and maybe more documented ....

there are several bug reports opened related to autoconfig, feel free to
contribute and/or vote !

http://bugzilla.mozilla.org/show_bug.cgi?id=229271
http://bugzilla.mozilla.org/show_bug.cgi?id=206294
http://bugzilla.mozilla.org/show_bug.cgi?id=222973
http://<email address hidden>/msg02784.html

aschroe1 wrote:

> jehan.procaccia schrieb:
>
>> getenv OK , just check in shell that the value of USER is what is expected :
echo $USER
>> your locPref above is wrong , don't add the "+" sign ! you (an I !) use +
sign in the the javascript file to concatenate strings, here you just have to
call the string:
>> lockPref("mail.identity.id1.useremail", env_user );
>
>
>
> Hello,
> I've got the solution; I dont't believe really
>
> -the first line of my js/cfg script has to begin with //
> -your tip leaving out the "+" sign in fornt of the variable
> (I tried this before, but without the first comment line)
> that's it! zzzz..zzzz..zzzzz
>
> Thank you very much for your support,
> merci bien (just another two of my few french words) :- ))
>
> -------------------------------------------------------------
> Alfred Schroeder - Lernstatt Paderborn -
>
> <email address hidden>
> -------------------------------------------------------------
>

I'am glad you finally made it work

we are about to form a community that use mozilla autoconfig, and hopefully
we'll be enough to assure that developpers keeps make this unvaluaible feature
work, and maybe more documented ....

there are several bug reports opened related to autoconfig, feel free to
contribute and/or vote !

http://bugzilla.mozilla.org/show_bug.cgi?id=229271
http://bugzilla.mozilla.org/show_bug.cgi?id=206294
http://bugzilla.mozilla.org/show_bug.cgi?id=222973
http://<email address hidden>/msg02784.html

aschroe1 wrote:

> jehan.procaccia schrieb:
>
>> getenv OK , just check in shell that the value of USER is what is expected :
echo $USER
>> your locPref above is wrong , don't add the "+" sign ! you (an I !) use +
sign in the the javascript file to concatenate strings, here you just have to
call the string:
>> lockPref("mail.identity.id1.useremail", env_user );
>
>
>
> Hello,
> I've got the solution; I dont't believe really
>
> -the first line of my js/cfg script has to begin with //
> -your tip leaving out the "+" sign in fornt of the variable
> (I tried this before, but without the first comment line)
> that's it! zzzz..zzzz..zzzzz
>
> Thank you very much for your support,
> merci bien (just another two of my few french words) :- ))
>
> -------------------------------------------------------------
> Alfred Schroeder - Lernstatt Paderborn -
>
> <email address hidden>
> -------------------------------------------------------------

FYI, there's a new preference being added in bug 86193.

Some comments:

Firstly the guide doesn't explain how to set the default homepage. I've tried
setting:
 pref("browser.startup.homepage", "http://www-xray.ast.cam.ac.uk/");
but firefox just dies if I put this in unix.js

Also, the guide suggests that sysadmins set things in all.js. This doesn't work
for most settings (at least on Linux). To set fonts, network proxies and paper
sizes, I had to use unix.js.

> Firstly the guide doesn't explain how to set the default homepage.

that's bug 178685

> Also, the guide suggests that sysadmins set things in all.js. This doesn't
> work for most settings (at least on Linux). To set fonts, network proxies and
> paper sizes, I had to use unix.js.

The doc says the platform-specific file (e.g unix.js) is loaded after all.js .
As Mozilla code changes constantly, we don't want to document what prefs are
loaded in platform-specific file.

See also: http://preferential.mozdev.org/

references (from bug 241534)
http://www.alain.knaff.lu/howto/MozillaCustomization/index.html
http://thegoldenear.org/toolbox/windows/docs/mozilla-pre-config.html
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html

Created an attachment (id=152002)
Configuration Configuration and Auto-Admin reference

WIP from bug 178685

I have confirmed that this bug exists in Mozilla/5.0 (Windows; U; Windows NT
5.0; en-US; rv:1.7) Gecko/20040514

The resolution based on Jehan's workaround is just to add a single line to the
prefcalls.js file which increments the start_pos value by 1

diff prefcalls.js.orig prefcalls.js.new
181a182
     start_pos += 1;

attachment 57051 <bug 89137 comment 35> introduced the space.

I can't see any reason for it.

Created an attachment (id=152586)
drop unwanted whitespace

Very good, I'am glad you finally corrected this bug .
However, in which release can I expect this patch beeing applied ?
Thanks .

(From update of attachment 152586)
r=alecf

(From update of attachment 152586)
sr=dmose

(From update of attachment 152586)
a=asa (on behalf of drivers) for checkin to 1.8a2

mozilla/extensions/pref/autoconfig/src/nsLDAPSyncQuery.cpp 1.11

I can confirm this bug is still present in Thunderbird 0.7.1/0.7.2, on Windows,
Linux and Solaris. This is with the official Windows Build (20040707), official
Linux build (20040626), and the contributed Sun Forte build (20040630).

OS Information:
Windows: Windows XP Professional, SP1
Linux: Red Hat Enterprise Linux 3, kernel 2.4.21-15.0.2.EL i686
Solaris: Solaris 5.9 4/04 release, sparc, Sun-Blade-100

> this should work fine if you build the pref extension

Compiling in the pref extension doesn't help. It does create the autoconfig
scripts in default/autoconfig/. However, preferences still aren't applied to
Thunderbird. Checking the web server's access logs shows that Thunderbird isn't
requesting the configuration file from the server.

online version of the draft (finally!):
http://wangrepublic.org/daniel/mozilla/prefs/

I'm not spending a lot of time w/ firefox, so if people can figure out more of
what goes on there, lets start a new document or make changes to this one.

Thanks for you documentation (attachement) and the wonderfull pages you opened on
http://wangrepublic.org/daniel/mozilla/prefs/ thanks to bugid=178685 :-).
However (I haven't read everything yet ...) I noticed on mozilla 1.7 on windows
palteform at least, that there's no more all.js file. To bad .. it's where I set
my general.config.filename directive for mozilla auto-config, cf:
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html
should I set it somewhere else or create an empty all.js file containing only
that directive ?
Thanks.

The document in the URL is outdated. First, the directory structure for prefs
has changed. Also, There's no information about how to lock a preference in the
UI, which can be critical for admins, and I haven't found a right way to do
this, just ignore the changes but the preference is reachable, and unknown
value. Please work a little more on this, even with basic examples (I've tried
changing the cache disk size, if you want to take it as example), together with
an additional file, in order to separate from original .js files.

The proper way to change preferences in a profile is via about:config these days.

As for the other items you mentioned, I'm not reading every single prefs bugs.
Is there a bug number you can provide, or can you be more specific? For example,
I don't know what you mean about the directory structure...

(In reply to comment #37)
> The proper way to change preferences in a profile is via about:config these days.

This contrasts with what's told in the url, since they're supposed to be
guidelines for corporation admins to provide specific default settings for their
corporations, avoiding spending a lot of time doing repeatedly and by hand the
same setting once and again.

> As for the other items you mentioned, I'm not reading every single prefs bugs.
> Is there a bug number you can provide, or can you be more specific? For example,
> I don't know what you mean about the directory structure...

Take a look at Mozilla 1.7.x directory structure, which is different from
previous versions, and the .js preferences files aren't in the same paths as before.

Way back when the very first version of Netscape was released it was very messy
for an administrator to set site defaults, and it has got harder and harder as
the years have gone by. The document
http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html
is good and describes a nice simple scheme, but I'm not convinced it works any
more (a previous comment hinted about new directory structures). I have created
a file defaults/pref/all.js on a Windows installation of Firefox 1.0, but it
seems to be ignored both for new and existing users. Have I done something silly
or is this other people's experience?

This stuff is important! If you want people to get a good impression of Mozilla
you need to help the guy who administers a large site make life as easy as
possible for the thousands of users under his or her control.

> The document
> http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html
> is good and describes a nice simple scheme, but I'm not convinced it works any
> more (a previous comment hinted about new directory structures). I have created
> a file defaults/pref/all.js on a Windows installation of Firefox 1.0
Hmmm. I think it might just be a matter of updating firefox.js instead of all.js.

I fully agree with your comments, though. Actually, this may not be a
documentation issue at all; perhaps the problem is not that the mechanisms are
undocumented, but that they are unnecessarily complex. I mean, why do we have to
mess around with byteshift etc.? And why do you have to set the config file name
in the first place? Why doesn't "general.config.filename" default to a file that
is normally not there, and may thus be added by a system admin without having to
update file from the distribution? Or even better, how about a site config
*directory* where all files are read as part of the init sequence?

(In reply to comment #40)

> Hmmm. I think it might just be a matter of updating firefox.js instead of all.js.
>

Sadly this doesn't seem to work either. I quite agree with your comments: the
problem is that the configuration mechanism is
(a) too complex
(b) doesn't conform with the documentation (i.e. is BUGGY!)
(c) keeps on changing from release to release.

I have been installing netscape and its successors on multi-user Unix systems
ever since Netscape first came out, and there has never been a release that
didn't force me to write a wrapper script to apply my site configurations. My
actual configuration lines have hardly changed at all, apart from when the
preference files switched to Javascript syntax, but every release I have wasted
hours fathoming out where to put them.

I've now hit a dead end trying to install it on a Windows system, because my
Windows scripting skills are pretty non-existent: if there isn't a simple
interface then I'm stuck.

If this is going to be moved to mozilla.org it should match the style and markup
guide, which it currently does not. If desired I can point out the problems in
more detail.

thunderbird looks for tbird.cfg, and expects it to be unobscured...

duh, sorry, it uses, as you say, whatever the general.config.filename is set to.
That file needs to be plain text, unobscured, unless you you've set the obscure
pref,

general.config.obscure_value

to whatever byte offset you want to obsucre by (mozilla used to use 7 or 13,
can't remember which...)

you're probably not getting this far, but you can turn on PRLogging for MCD:

set NSPR_LOG_MODULES=MCD:5
set NSPR_LOG_FILE=c:\log.txt

I don't know if this applies to the windows version or not, but I've found in
the 0.8 relase for thunderbird on linux that general.config.obscure_value is set
twice, with two contradictory values. In greprefs/all.js its set to:

pref("general.config.obscure_value", 13); // for MCD .cfg files

and in defaults/pref/all-thunderbird.js its set to:

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

with second instance overriding the first.

Now I see that all.js file is opened on a different folder since 1.7.2 on linux.
it used to be in MOZILLA_HOME(here /usr/lib/mozilla-1.7.3/)/default/pref, now
it's in MOZILLA_HOME/grepref/ .
The problem is that this directory is by default only readable by root (700), so
users on my stations that use mozilla autoconfig (general.config.filename
directive in all.js) don't get the autoconfiguration set anymore :-( .

A workaround is to set grepref directory to 755, but is this safe ?
Second question, where should I but general.config.filename directive in the
future (default/pref/all.s or grepref/all.js ?)

thanks.

PS: I will update my mozilla autoconfig doc in consequence ...
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html

Problem Still Exists in Version 0.9

Any chance this will be fixed in 1.7.x?

<email address hidden>: given that it's sat here w/ the approval1.7.x? flag
for four months, i doubt it.

(From update of attachment 152586)
Sorry about that.

mozilla/extensions/pref/autoconfig/src/nsLDAPSyncQuery.cpp 1.7.2.1

I'm still here, and can do some updating, although I don't use firefox much (I
use a lot of camino and mozilla).

The best way to keep this document updated is to reference bugs that describe
prefs system changes. I rarely get updates from the developers, so I depend on
contributors to point me in the right direction.

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
http://www.int-evry.fr/s2ia/user/procacci/netscape/en/mozilla-autoconfig-en.html

I've tested in my autoconfig javascript this:

defaultPref("browser.startup.homepage", "http://www.int-evry.fr/");

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", "http://www.int-evry.fr/");
then just after use unlockPref() to reanable modification -> no success :-(
I've also tried to use defaultpref and remove the
browser.startup.homepage
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.

Thanks.

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

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","http://www.int-evry.fr/");
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", "http://www.int-evry.fr/");
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 region.properties 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 region.properties with you post, and found these doc:
http://www.geniusweb.com/LDP/HOWTO/Mozilla-Optimization/configure.html and
http://mozdoc.burlco.org/bowels.html

Please let us know what is the correct documentation that define officialy
preference settings , and is autoconfiguration a good method for the futur ...
thanks.

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
chrome://navigator-region/locale/region.properties
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
browser.startup.homepage=www.int-evry.fr
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:///region.properties or alternatively you can use a file URL such as
file://///smbserver/share/region.properties or even a remote URL such as
http://webserver/region.properties or ftp://ftpserver/region.properties

Some feedback
1) there're also [mozilla app directory]/greprefs/*.js which are common among
all gecko applications [except Minimo, there's a bug on that, iirc], and which
also used to set default values.
2) in firefox extensions can have their own default preferences set in
[extension dir]/defaults/preferences/*.js, where [extension dir] is ususally
[profile]/extensions/[extension GUID], but may also be in [app
dir]/extensions/[GUID] for global installations, I think.
3) "A preferences file is a simple JavaScript file" is quite confusing. It isn't
Javascript file anymore. It used to be, that's where .js extension and some of
syntax come from. But it's not JS, it is parsed not by js but by another
(simpler) parser.
4) A link to http://preferential.mozdev.org/ (unless something better is put on
moz.org) and a notice about about:config
<http://kb.mozillazine.org/index.phtml?title=About:config> would be nice.
5) nit: "In the profile directory are two user pref files: prefs.js and user.js.
prefs.js is automatically generated ". A new line after the first sentence would
make the reading easier, I think. (ie. "user.js\n prefs.js") The dot separating
two sentences is not visible enough (as there are too many dots nearby :)
6) "None <a href="#filew-def-special">platform-specific</a> .js". The target
anchor does not exist in the document.
7) "Usually when the user specifically commits a preference change via user
interface such as the Preferences dialog, the application saves the change by
overwriting prefs.js". Suggesting <em>Ususually</em>. For example, changing it
from about:config doesn't seem to rewrite prefs.js on current trunk firefox
build. Clicking ok in options dialog does rewrite it though. In fact the rewrite
only happens *only* when nsIPrefService::savePrefFile(null) is called. Afaik,
many/most extensions don't do that.
8) "Note: <b>Note</b> preference names are case-sensitive."
9) "If you have Mozilla 1.4". Moz 1.4 or later or Firefox

http://www.mozilla.org/catalog/end-user/customizing/briefprefs.html says
"feedback and comments here", so here is mine

I can't find out what fcc_folder_picker_mode means. I've come across it in my
thunderbird installation, while trying to debug something else. But I don't
know what it means, and there does not seem to be a cannonical reference to all
these preferences anywhere in the documenation.

I'd like to see a full, maintained, list of what they all are and mean. Does
anyone know where it is?

It seems it doesn't function more in TB 1.02.

Permit me a remark : Centralized configuration management is a big request
before beginning any enterprise deployment.

I can confirm this still doesnt work on at least Win32 either.

On a side note - is there any project/group setup to track enterprise
Thunderbird needs. As this issue alone is a significant hinderence in regards to
deploying Thunderbird to my aprox 500 users. Our users are average
non-technicnal folks being migrated from GroupWise - and therefore should never
have to manually configure most of the client's settings.

We're currently configuring and forcing settings with a combination of grep,
sed, and batch files, and manually editing the the mail.jar file to hide certian
UI fields. Nasty hacks at best...

Indeed , since my fedora Core 2 system recently updated from mozilla 1.7.3 to
mozilla-1.7.6-1.2.5, now there's no need to hack prefcalls.js with "start_pos
+=1;", in fact if I continue with this hack I lose (as expected) the first
letter of the email address (fetch from ldap) .

Thanks for the correction ! this bug is really solve to me now :-) .

By the way (out of subject !) ... is autoconfig still working with
firefox/thunderbird (I desperatly hope so !) .

Gregg Berkholtz wrote:

> In bug 222973, you mentioned that setting up a community to help track and/or
manage Mozilla/Firefox/Thunderbird enterprise needs. Did you ever do this? If
so, how do we join?

Jehan Procaccia writes :

no, I've just hoppened several bug on bugzilla, but that's all .
Actually I don't know how many people use autoconfig, but this tool is very
usefull ! and I hope it will still work with firefox/thunderbird (I haven't
tested yet, but in next september our 2000 students will use Fedora Core 3 or 4
which comes with these tools now ...)

Do you have an idea on how to create or maybe join an already existing
autoconfig user's community ?

I've created a guide describing how to setup Autoconfig with Mozilla Firefox.
Take a look:
http://mit.edu/~firefox/www/maintainers/autoconfig.html

I also have a brief writeup describing how autoconfig is setup at MIT, and a
link to the relevant files:
http://mit.edu/~firefox/www/maintainers/config.html

Created an attachment (id=181580)
the fix

fixed for 1.1

Hello,

I confirm the NEED for autoconfig ( or Mission Control Server whatever you call
it ...).
In our school, we "autoconfig" our 2000 students settings for mozilla mail an
navigator. In next september we'll be using Fedora Core3 which replaces by
default mozilla with Firefox and Thunderbird. I expect to keep on using
autoconfig ... as I documented it on (as already mentioned in this bug-report)
http://www.int-evry.fr/mci/user/procacci/netscape/en/mozilla-autoconfig-en.html
Now I tried to use it with thunderbird 1.0.2, but with no success. Maybe
beacause it is due to work only with 1.1 released !? as mentioned just above !.
Anyway, is the use of autoconfig with thunderbird is documented somewhere apart
from this bug report where I just learnt that the config file should be called
"tbird.cfg" . but where should it be positioned ? :
/usr/lib/thunderbird-1.0.2 ?

although I export NSPR_LOG_MODULES=MCD:5 ; export
NSPR_LOG_FILE=/tmp/thunder.txt , there is nothing written in my thunder.txt
debug file :-(

You also mention compiling thunderbird with -enable-extensions=wallet,pref, but
how do you check that a package distribution of thunderbird (FC3 RPM) is compile
with that option !? in firefox you go to the URL "about:buildconfig" but here ??

Finally, I should mention that firefox 1.0.3 seems to allow autoconfig to work ,
but I still have lot of problems ... especialy with ldap queries
the getLDAPAttributes functions fails :-(
error popup messages is:
"Error: getLDAPAttributes failed: TypeError:
Components.classes[LDAPURLContractID] has no properties"
Any clues on that (I did removed the --disable-ldap in compile options !)
Autoconfig for firefox is VERY well documented on
http://mit.edu/~firefox/www/maintainers/autoconfig.html
but it doesn't uses ldap functions ... but maybe I'am out of subject here , I
should propably open a bug report on firefox, but if you have an idea before ...
that would help .

thanks.

Hello,
We NEED autoconfig too for thunderbird, for about 15000 users in a large
centralized deployment (we have one for netscape communicator 4.7 since 1998).
Waiting for 1.1.
Thanks.

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Fedora/1.7.8-1.3.1

firefox 1.0.3 seems to allow autoconfig to work,
Autoconfig for firefox is VERY well documented on
http://mit.edu/~firefox/www/maintainers/autoconfig.html
and partialy (for mozilla 1.x) in my doc
http://www.int-evry.fr/s2ia/user/procacci/netscape/en/mozilla-autoconfig-en.html

but I still have lot of problems ... especialy with ldap queries
the getLDAPAttributes functions fails :-(
error popup messages is:
"Error: getLDAPAttributes failed: TypeError:
Components.classes[LDAPURLContractID] has no properties"
Any clues on that (I did removed the --disable-ldap in compile options !)

Reproducible: Always

Steps to Reproduce:
1. ask for autoconfig:

$ tail -6 /usr/lib/firefox-1.0.4/greprefs/all.js
// autoconfig jehan
pref('general.config.obscure_value', 0);
pref('general.config.filename', 'firefox.cfg');

2.
edit the firefox.cfg file

//put everything in a try/catch
try {

//simple lockpref that do work :-), just to check that autoconfig did something
//Privacy & Security
defaultPref("signon.rememberSignons", false);

//Get username, for the ldap querie
 var env_user = getenv("USER");
/* 2) define processLDAPValues() here (because if set after "3)" below it
doesn't work !) processLDAPValues which is eventually called by
getLDAPAttributes() just below,
 check getLDAPAttributes() code from
$MOZILLA_HOME/defaults/autoconfig/prefcalls.js to see the inside call to "user
defined" processLDAPValues
*/
function processLDAPValues (values) {
 if(values) {
      // set the global var with the values returned from the LDAP query
      ldap_values = values;
    var uid = getLDAPValue ( values ,"uid" );
    var cn = getLDAPValue ( values ,"cn" );
    var mail = getLDAPValue ( values ,"mail" );

    }
  }
// 3) Call Ldap servers to get Ldap Attributes (mail & cn) , this will finally
call processLDAPValues , "2)" just above.
  getLDAPAttributes("ldap3.int-evry.fr","ou=people,dc=int-evry,dc=fr","uid=" +
env_user,"uid,cn,mail");

//Debug with popup error messages, that doesn't work anymore :-( !! why ??
var env_mozdebug= getenv("MOZILLA_DEBUG");
if (env_mozdebug) { displayError("NO ERROR , just a test, cn =" + cn); }
// try a simple lockpref for debuugin, that one is never set :-(, code might
crash before that line ?
lockPref("browser.startup.homepage", "http://www.int-evry.fr/");

// Close the try, and call the catch()
} catch(e) {
  displayError("lockedPref", e);
}

3. start firefox

Actual Results:
in 1.0.3
popup messages is:
"Error: getLDAPAttributes failed: TypeError:
Components.classes[LDAPURLContractID] has no properties"

in 1.0.4 nothing happens :-( , the file seems to start beeing parse as the first
lockpref is set, but not the lastone at the end of the script

Expected Results:
ldap values get retrieved so that I can set aother preferences base on the email
address of the user grabbed from ldap ! that will be more usefull in thunderbird
actually ...

Related recents buzilla:

https://bugzilla.mozilla.org/show_bug.cgi?id=...

i bet firefox doesn't build/ship w/ ldap :)

that works :-)

Indeed I hadn't rebuilt my firefox 1.0.4 with ldap enable (removed
--disable-ldap !). However I did do it in 1.0.3 where I finnaly ened on "Error:
getLDAPAttributes failed: TypeError:" ... ??

Anyway, it does work now for my fresly built firefox .
demonstration:

for a minimun debug:
$ export NSPR_LOG_MODULES=MCD:5
$ export NSPR_LOG_FILE=~/firefox.log

[root@calaz /usr/lib/firefox-1.0.4]
$ tail -6 greprefs/all.js
// autoconfig jehan
pref('general.config.obscure_value', 0);
pref('general.config.filename', 'firefox.cfg')

firefox.cfg:

try {
var env_user = getenv("USER");
//ldap values
function processLDAPValues (values) {
 if(values) {
      ldap_values = values;
    var cn = getLDAPValue ( values ,"cn" );
    var mail = getLDAPValue ( values ,"mail" );
    var URL = getLDAPValue ( values ,"labeledURI" );
//set the firefox home page to the personnal user's page retrived from ldap
lockPref("browser.startup.homepage", URL );
    }
  }
// ldap querie
  getLDAPAttributes("ldap3.int-evry.fr","ou=people,dc=int-evry,dc=fr","uid=" +
env_user,"uid,cn,mail,labeledURI");
} catch(e) {displayError("lockedPref", e);}

openldap log when firefox start, I do see the querie

May 25 12:07:08 babylone slapd[8948]: conn=161 op=1 SRCH
base="ou=people,dc=int-evry,dc=fr" scope=2 filter="(uid=procacci)"
May 25 12:07:08 babylone slapd[8948]: conn=161 op=1 SRCH attr=cn mail labeledURI

when firefox shows up I do start on my homepage as recoreded in ldap :-)

Just a remark, the firefox.log do show the read of firefox.cfg , but then I get
warnings that I don't really understand ... I suppose I get these because I
recompile firefox with enable debug !

$ cat firefox.log
-1209947296[8067548]: general.config.filename = firefox.cfg
-1209947296[8067548]: evaluating .cfg file firefox.cfg with obscureValue 0
-1209947296[8067548]: WARNING: chrome: failed to get base url for
chrome://autoconfig/locale/autoconfig.properties -- using wacky default, file
nsChromeRegistry.cpp, line 531
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsPermissionManager.cpp, line 623
-1209947296[8067548]: WARNING: the property eo already exists
, file nsPersistentProperties.cpp, line 282
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsSyncLoadService.cpp, line 633
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsXBLService.cpp, line 1236
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsSyncLoadService.cpp, line 633
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsXBLService.cpp, line 1236
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsSyncLoadService.cpp, line 633
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsXBLService.cpp, line 1236
-1209947296[8067548]: WARNING: requested removal of nonexistent window
, file nsWindowWatcher.cpp, line 944
-1209947296[8067548]: WARNING: nsExceptionService ignoring thread destruction
after shutdown, file nsExceptionService.cpp, line 191
-1209947296[8067548]: WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(rv)) failed, file
nsGlobalHistory.cpp, lin...

(In reply to comment #14)
> Hello,
> We NEED autoconfig too for thunderbird, for about 15000 users in a large
> centralized deployment (we have one for netscape communicator 4.7 since 1998).
> Waiting for 1.1.
> Thanks.

If there is a urgent need for autoconfig, you can always compile Thunderbird
yourself with
ac_add_options --enable-extensions=default,pref (that also works with 1.0.x)

Indeed that works with the -enable-extensions compile time options !
I've just documented it on:
http://www.int-evry.fr/s2ia/user/procacci/netscape/en/mozilla-autoconfig-en.html#htoc8
I don't know why it was marked as "fixed for 1.1" as it works even on 1.0.2 !?

however you need to recompile , it's easy (for me !) on linux, but not that much
on windows ..., see my problems on http://forums.mozillazine.org/ ->
thunderbird Build -> windows Thunderbird build
 http://forums.mozillazine.org/viewtopic.php?t=276014

hope these discussions will enhence to use and need of autoconfig .

It appears getLDAPAttributes() Win32 still fails on Win32. The popup error
message is:
 Netscape.cfg/AutoConfig failed. Please contact your System Administator
 Error: getLDAPAttibutes failed: [Exception... "Component returned failure code:
0x80570018 (NS_ERROR_XPC_BAD_IID)[nsIJSCID.createInstance]" nsresult:
"0x80570018 (NS_ERROR_XPC_BAD_IID)" Location: "JS frame :: file:///c:\Program
Files\Mozilla Thunderbird\defaults\autoconfig\prefcalls.js :: getLDAPAttributes
:: line 176" data:no]

This is on TBird version 1.0+ (20050626) - which from what I understand should
already have both autoconfig and ldap support compiled in. Correct?

My testing/static getLDAPAttributes() call:
getLDAPAttributes("ldap.domain.com","ou=People,dc=domain,dc=com","uid=validuid","uid,cn,mail
");

The DN which contains the valid UID is actually under
ou=PDX,ou=People,dc=domain,dc=com, though I assume the lookup will search
subcontainers without issue.

(In reply to comment #7)
> I've created a guide describing how to setup Autoconfig with Mozilla Firefox.
> Take a look:
> http://mit.edu/~firefox/www/maintainers/autoconfig.html
>
> I also have a brief writeup describing how autoconfig is setup at MIT, and a
> link to the relevant files:
> http://mit.edu/~firefox/www/maintainers/config.html

Charles has done an excellent job here of documenting the baroque Mozilla
configuration process. But it would be much better if the software was changed
so that much of the complexity vanished. For example:
(1) The configuration file should not have to reside in the software directory,
because that way it is highly likely to get lost or overwritten whenever the
software is upgraded. Instead the software should follow Unix FHS standards and
look in /etc/opt/mozilla/ (perhaps followed by some other places).
(2) There should be a sensible default name, e.g. siteprefs.cfg. At the moment
the administrator has to use the old complicated user preference scheme just to
enable the new simpler one.
(3) What on earth is the ROT13 business for? The default should be to accept a
plain text file (and maybe accept ROT13 for backward compatibility).

My comments are Unix-orientated; I guess Windows doesn't have an equivalent of
the /etc directory. But if these changes were made then most of section 2 could
be eliminated and replaced by something like

You need to put your site preferences in a file called siteprefs.cfg. On Unix
this file should be put in the directory /etc/opt/mozilla; on Windows put it in
the base of the Mozilla installation directory.

Bob

It appears I was in error. As Thunderbird is apparently still not compiled with
the necessary mission control LDAP code enabled. Is there any chance such
support will be added to 1.1?

I also confirm that latest nightly build doesn't support ldap
TB 1.0+ (20050721) -> yesterday build .
I also get the error while calling getLdapAttributes() from prefcall.js, error :

Netscape.cfg/AutoConfig failed. Please contact your System Administator
 Error: getLDAPAttibutes failed: [Exception... "Component returned failure code:
0x80570018 (NS_ERROR_XPC_BAD_IID)[nsIJSCID.createInstance]" nsresult:
"0x80570018 (NS_ERROR_XPC_BAD_IID)" Location: "JS frame :: file:///c:\Program
Files\Mozilla Thunderbird\defaults\autoconfig\prefcalls.js :: getLDAPAttributes
:: line 176" data:no]

however, other autoconf settings do work , but we cannot set pref from ldap
values which is very anoying for autoconfiguring email preferences ... :-(

I also tested the latest stable TB 1.0.6 (20050716), I was positively surprised
to see the presence of the autoconfig sub-directory, which mean that is is now
ship with --enable-extensions=pref , good !, unfortunatly, I don't know why but
TB 1.0.6 complety ingore autoconfig, although I did put in pref/all.js :
//autoconfig
pref("general.config.obscure_value", 0); // for MCD .cfg files
pref('general.config.filename', 'thunderbird.cfg'); // for MCD .cfg files
and put thunderbird.cfg in the root directory of TB, nothing is read :-( .

I'am afraid to be forced to use again mozilla (probably 1.7.10 for which
everything works fine) instead of firefox/thinderbird for our next september
academic year .
Thanks to let me know if there's a possible solution before .

Can this bug be re-opened, as this issue still appears unresolved. Or should a
new bug report be filed for just enabling the LDAP support noted in the last two
comments.

the latter, please, thx!

Does anyone know what The Thunderbird compile-time switch is for enabling LDAP
AutoConfig? Is it the same as FireFox's (--disable-ldap)?

If anyone wishes to vote for LDAP AutoConfig support in TB1.1. I've opened Bug
302096

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:
Firefox: http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey: http://www.mozilla.org/projects/seamonkey/

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?

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Reassigning Daniel's www.mozilla.org bugs to default assignee.

in firefox 1.5.0.3 it ldap calls in autoconfig are still unavailable ! :-(
I supose it has been compiled with --disable-ldap ?

How can I check the compilation options used ?
there's the URL "about:buildconfig" in firefox, but is there an equivalent in thunderbid ?
The only way I could try to figure out which options have been used, is to get the source RPM and check spec files:
On my fedora core 5 I took thunderbird-1.5-6.src.rpm
the SOURCE directory contains a thunderbird-mozconfig which is finally converted to .mozconfig in the top source dir (mozilla) , it contains:
. $topsrcdir/mail/config/mozconfig

ac_add_options --with-system-nspr
ac_add_options --with-system-nss
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-system-png
ac_add_options --with-pthreads
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --disable-installer
ac_add_options --enable-optimize="$RPM_OPT_FLAGS"
ac_add_options --enable-xinerama
ac_add_options --enable-default-toolkit=gtk2
ac_add_options --disable-xprint
ac_add_options --disable-strip
ac_add_options --enable-pango
ac_add_options --enable-system-cairo
ac_add_options --enable-svg
ac_add_options --enable-canvas

export BUILD_OFFICIAL=1
export MOZILLA_OFFICIAL=1

and $topsrcdir/mail/config/mozconfig contains:
$ cat mail/config/mozconfig
# This file specifies the build flags for Thunderbird. You can use it by adding:
# . $topsrcdir/mail/config/mozconfig
# to the top of your mozconfig file.

mk_add_options MOZ_CO_PROJECT=mail
ac_add_options --enable-application=mail

ldap options (--disable-ldap) or autoconfig options (--enable-extensions=pref) don't appear anywhere in those files !?
However, I do confirm that autoconfig and autoconfig through ldapcalls (getLDAPAttributes) does work fine in thunderbird (not in firefox :-( ) . The only solution I see that in the defaults, --disable-ldap is not used and --enable-extensions=pref is set .

Please let me know how to check for sure, which compilation options (set and defaults) have been used in thunderbird and in firefox .
thanks.

Please check http://landfill.mozilla.org/mxr-test/mozilla1.8.0.x/source/configure.in#4062 and following lines.
For LDAP support to be compiled in you would need MOZ_LDAP_XPCOM=1 which is only set for SeaMonkey and Thunderbird.

indeed ! you might be right .
I patched configure.in to include "MOZ_LDAP_XPCOM=1" in the browser I recompiled firefox for my FC5, unfortunatly autoconfig ldap calls are still unavailable :-(
I checked configure.in and .mozconfig and even after recompilation the about:buildconfig, none of them show the --disable-ldap !
what else am I missing ?

here's the patch i made:
[root@b008-02 SOURCES]# cat firefox-1.5-autoconfig-ldap.patch
diff -ur mozilla.orig/configure.in mozilla/configure.in
--- mozilla.orig/configure.in 2006-05-18 09:30:33.000000000 +0200
+++ mozilla/configure.in 2006-05-18 10:00:36.000000000 +0200
@@ -4094,6 +4094,7 @@
  MOZ_PHOENIX=1
  MOZ_APP_VERSION=$FIREFOX_VERSION
  MOZ_EXTENSIONS_DEFAULT=" cookie xml-rpc xmlextras pref transformiix
universalchardet webservices inspector gnomevfs auth permissions reporter"
+ MOZ_LDAP_XPCOM=1
  AC_DEFINE(MOZ_PHOENIX)
  ;;

Is there a way to check after compilation that MOZ_LDAP_XPCOM=1 has really been taken ? I tried ldd on firefox-bin to look for ldap libraries, none appears, anyway I did the same ldd on thunderbird-bin, none either , but it (ldap calls) does work on thunderbird , how can I check for sure that ldap support is included in the binary .
Thanks

Did you manually re-run autoconf after patching configure.in? By default, build process won't do this for you automatically.

no,
in fact I use rpmbuild , which read a firefox.spec and automatically untar, patch, compile, and create an rpm package.
the build section in the firefox.spec file contains:
%build

export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | %{__sed} s/-O2/-Os/`
MAKE="gmake %{?_smp_mflags}" make -f client.mk build

Indeed I don't see any autoconf nor ./configure in here !
I'am lost in all those pre-conf files -> client.mak , client.mk, configure.in, configure etc ...
running autoconf manually generate an error, but maybe running it in the flow of the rpm .spec file will allow it to run ?
what do you recommend ?, remember, I just want to enabled ldap autoconfig calls for firefox .

[root@b008-02 mozilla]# pwd
/usr/src/redhat/BUILD/mozilla
[root@b008-02 mozilla]# autoconf
build/autoconf/altoptions.m4:156: error: m4_defn: undefined macro: _m4_divert_diversion
build/autoconf/altoptions.m4:153: MOZ_READ_MOZCONFIG is expanded from...
build/autoconf/altoptions.m4:156: the top level
autom4te: /usr/bin/m4 failed with exit status: 1

(In reply to comment #10)
> no,
> in fact I use rpmbuild , which read a firefox.spec and automatically untar,
> patch, compile, and create an rpm package.
> the build section in the firefox.spec file contains:
> %build
>
> export RPM_OPT_FLAGS=`echo $RPM_OPT_FLAGS | %{__sed} s/-O2/-Os/`
> MAKE="gmake %{?_smp_mflags}" make -f client.mk build
>
> Indeed I don't see any autoconf nor ./configure in here !

That make command eventually causes configure to run. However, it does not cause autoconf to regenerate configure from configure.in, which would be necessary for the fix you propose to work. As a workaround, try patching configure directly instead of patching configure.in.

Great , that works, I now patched directly configure script and autoconfig + ldap calls do work now .
I updated my mozilla family autoconfig doc accordingly :
http://www.int-evry.fr/s2ia/user/procacci/netscape/en/mozilla-autoconfig-en.html#htoc18

Any plans to include by default MOZ_LDAP_XPCOM=1 in the browser) (firefox !) ?
If not, any clues on how to compile my own packages on the windows platform ?
I tried that a year ago whitout sucess (http://forums.mozillazine.org/viewtopic.php?t=276014)

FYI here's the patch I applied in my RPM firefox.spec file:

[root@b008-02 /usr/src/redhat/SOURCES]
$cat firefox-1.5-configure-ldap.patch
--- mozilla.orig/configure 2006-05-18 09:30:33.000000000 +0200
+++ mozilla/configure 2006-05-22 12:03:42.000000000 +0200
@@ -12689,6 +12689,7 @@
   MOZ_XUL_APP=1
   MOZ_PHOENIX=1
   MOZ_APP_VERSION=$FIREFOX_VERSION
+ MOZ_LDAP_XPCOM=1
   MOZ_EXTENSIONS_DEFAULT=" cookie xml-rpc xmlextras pref transformiix universalchardet webservices inspector gnomevfs auth permissions reporter"
   cat >> confdefs.h <<\EOF
 #define MOZ_PHOENIX 1

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-1.5.0.10/firefox.cfg, which has:

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

/usr/lib/firefox-1.5.0.10/region.properties:

browser.startup.homepage=https://www.cora.nwra.com/intranet

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", "http://www.int-evry.fr/" );
in my /usr/lib/firefox-1.5.0.10/firefox.cfg
So it does set the homepage to http://www.int-evry.fr/ 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 !
http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig

 I've recently tested with firefox 2.0.0.2 on fedora core 6 , apparently default configuration options still don't support ldap calls in autoconfig/MCD (MOZ_LDAP_XPCOM=1 in mozilla/configure.in is not set by default I suppose).
I've updated the MCD/autoconfig Doc accordingly:
http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig#Firefox_2.x

Howerver, and fortunatly, because it's realy there that ldap calls are needed ! it works fine in thunderbird 2 beta2 :
http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig#Thunderbird_2.x_beta_2

thanks to developers/packagers, to maintain that unvaluable feature (MCD/autoconfig) for enterprise deployements .

FYI, I've just updated the doc on autoconfig/MCD feature on mozilla products with TB 2 beta 2 and firefox 2.x

http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig#Thunderbird_2.x_beta_2

http://developer.mozilla.org/en/docs/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig#Firefox_2.x

I've recently had time to re-read this document, in the context of a new-found curiosity about Camino...

I've made some gramatical and link cleanup changes, and also moved about:config to the top, in refrence to how to make changes. I think this servers the most common audience.

Here's my personal todo list:

users.js - should emphasis the advantage of being able to use comments (per #3)

I've reviewed all the comments up to #36, about the directory info being out of date. I'll look into that now.

Since the original document, I've learned enough c++ to read some of the pref loading code.

Changes: