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 )

(From update of attachment 316056)
a1.9+=damons

Fix checked in.

Now it works again.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9pre) Gecko/2008042204 Minefield/3.0pre

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.

    I'm still seeing the same issue with

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b5) Gecko/2008042314 Red Hat/3.0b5-0.beta5.3.el5 Firefox/3.0b5

but I expect it's because 3.0 beta 5 doesn't have the fix attached here... What version is that fix checked into? Or, how do I apply it?

There will be a release candidate for FF3 released very soon. you'll be able to test it there.

or you can download the latest nightly:

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

    Awesome, thanks!

    ....aaaand nope, doesn't work for me in the release version on Linux, sorry. Did it get regressed again?

Here's my version info and contents of the config files:

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9) Gecko/2008061517 Red Hat/3.0-2.el5 Firefox/3.0

/usr/lib/firefox-3.0/dw-config.cfg:
//point to the autoconfig directory on the web server
lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/");

/usr/lib/firefox-3.0/defaults/preferences/vendor.js:
pref("general.config.obscure_value", 0);
pref("general.config.filename", "dw-config.cfg");

   I've tried bypassing dw-config.cfg in the same manner Kohei Yoshino did. This eliminates the pop-up error 'Failed to read the configuration file", instead it fails silently.

(In reply to comment #14)
WFM... Could you try again like this?

/usr/lib/firefox-3.0/dw-config.cfg:
// This file is empty

/usr/lib/firefox-3.0/defaults/preferences/vendor.jsa:
// point to the autoconfig *file* (not directory) on the web server
pref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/dw-config.jsc");
// this *vendor name* should be the same as the filename below
pref("general.config.vendor", "dw-config");
pref("general.config.filename", "dw-config.cfg");

(In reply to comment #15)
> /usr/lib/firefox-3.0/defaults/preferences/vendor.jsa:

vendor.jsa -> vendor.js

    Thanks, Kohei, that's what I meant when I said I tried bypassing dw-config.cfg in the same manner as you. I tried it again, following your suggestions exactly: epic fail. Same issue, although this time I got the pop-up error "failed to read configuration file".

    However, I think that may be a different thing. Firefox is trying to read dw-config.cfg as the config file, which is blank.

I set:

setenv NSPR_LOG_MODULES MCD:5
setenv NSPR_LOG_FILE ~/mozilla.log
setenv AUTOCONFIG_DEBUG 1

to enable logging in the MCD module. This will cause Firefox to note when it reads the autoadmin.js file, and where it reads it from, and it reports:

-134400304[805e790]: general.config.filename = dw-config.cfg

not real helpful, eh?

So I tried something else, something much simpler. It's not really necessary to redirect Firefox to a URL to get the config file; that's just for convenience. Firefox will read settings directly from the cfg file, so I put one setting in there:

/usr/lib/firefox-3.0/defaults/preferences/vendor.js:
pref("general.config.obscure_value", 0);
pref("general.config.filename", "dw-config.cfg");

/usr/lib/firefox-3.0/dw-config.cfg:
pref("general.config.vendor", "dw-config");

    Still won't read that file - same error. At the suggestion of Red Hat engineering, I also tried using the /usr/lib/xulrunner directories instead of /usr/lib/firefox: this also didn't work.

    So is this just me, or is it failing for others too?

    I figured it out. Well, Red Hat did. Firefox 3 in Linux requires a link in /usr/lib/firefox-3.0/defaults/ that points to /usr/lib/xulrunner-1.9/defaults/autoconfig. Once that link is there, the autoconfig works properly.

    Not sure if that link should be part of the base Firefox package, or packaged up by Red Hat engineers. I suspect the latter. Anyway, my contributions to this thread are, I believe, finished.

Thanks for the help!

Anthony, I'am glad it finally worked for you, so I try myself to run it. I use fedora9 in 64 bit , so the lib64 directory in path below !

First I wonder where did your set the "pref("general.config.filename", "dw-config.cfg");" in:

/usr/lib64/firefox-3.0/defaults/preferences/all-redhat.js
or in
/usr/lib64/xulrunner-1.9/greprefs/all.js

next about the link RedHat suggested, I did as you recommended that

[root@localhost /usr/lib64/firefox-3.0/defaults]
$ ln -s /usr/lib64/xulrunner-1.9/defaults/autoconfig/ ./autoconfig

and indeed the .cfg file got finally readed, thanks for the advice :-)
could you give us an example of your dw-config.cfg, because mine generate error now :-( .

Thanks

    Yeah, I'll be happy to show my configuration again.
    Jehan, instead of using all-redhat.js I created a new file (Firefox is smart enough to read every js file in /usr/lib<64>/firefox-3.0/defaults/preferences/) called vendor.js.

/usr/lib/firefox-3.0/defaults/preferences/vendor.js:
pref("general.config.obscure_value", 0);
pref("general.config.filename", "dw-config.cfg");

/usr/lib/firefox-3.0/dw-config.cfg:
//point to the autoconfig directory on the web server
lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/");

and finally, the link you described above:

/usr/lib64/firefox-3.0/defaults/autoconfig --> /usr/lib64/xulrunner-1.9/defaults/autoconfig

    I found that if the 'lockPref("autoadmin.global_config_url","<your_url>")' line is the first line in the dw-config.cfg file, it gave me errors. That comment line eliminated the error. (?)

    dw-config-cfg points to a general directory, rather than a specific file, because I use the same two files for Mozilla, Thunderbird and Firefox: that directory contains an index.cgi that determines the software being used with $ENV{'HTTP_USER_AGENT'} and then points to the appropriate autoconfig file.

    Hope that helps.

Ok then your dw-config.cfg uses a redirection to a "global_config_url":
lockPref("autoadmin.global_config_url", "http://proxyconfig/autoconfig/");

Mine doesn't redirect to a URL but sets (lock !) preferences in itself , sample few first line on mine dw-config.cfg (mine is called firefox.cfg ):

//put everything in a try/catch
try {
//Privacy & Security
defaultPref("signon.rememberSignons", false);
lockPref("browser.startup.homepage", "http://www.it-sudparis.eu/");
etc ...

I did that once as the "global_config_url" was broken some times ago ,and then I stick with a local to each station configuration file instead of a centralize conf file on a web server as you do, we propagate that file with cfengine on linux and powershell on windows stations (about 300 stations) . Eventually, I did that, because I though that it adds a degree of independance on the web server availability .

About a comment line at the begining of the file, I also had to do it , but can't explain why, probably that the parser needs that !?

However, I'am interested in the way you use a unique file for Mozilla, thunderbird and firefox based on an index.cgi and $ENV{'HTTP_USER_AGENT'}, can you give us a copy of you index.cgi and the common configuration file for the 3 applications ?

Thanks.

    I may have been unclear: I use the same vendor.js and dw-config.cfg file for all three packages (Firefox, T-bird, and Mozilla). Each of those has their own config file, called firefox.js, etc. The index file and its module are written in perl. Here they are:

http://proxyconfig/autoconfig/index.cgi:
#!/usr/bin/perl -w
use strict;
use configFilename;
#Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5) Gecko/20031007
#Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
my $config_path = 'resources/js';
my $default_config = 'common-config.js';
my $config_file;
$config_file = $config_path . '/' . get_config_filename();
if( ! -e $config_file ) {
    $config_file = $config_path . '/' . $default_config;
}
print ("Content-type: application/x-javascript-config\n\n");
open(TMPFILE, $config_file);
while(<TMPFILE>) {
    print;
}
close(TMPFILE);

and

http://proxyconfig/autoconfig/configFilename.pm:
#!/usr/bin/perl -w
sub get_config_filename
{
    my $browser = 'mozilla';
    my $user_agent = $ENV{'HTTP_USER_AGENT'};
    my $version;
    $browser =
    ($user_agent =~ /Firefox/) ? 'firefox' :
    ($user_agent =~ /Thunderbird/) ? 'thunderbird' :
    ($user_agent =~ /Seamonkey/) ? 'mozilla' :
                                  'mozilla'; #default
    return $browser . '-config' . '.js';
}

This still doesn't seem to work on Windows XP

Adding pref("general.config.filename", "mozilla.cfg");
to the end of all.js causes FF not to start with

Failed to read the configuration file. Please contact your system administrator.

This is on XP SP3

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0

Indeed, on windows autoconfig for firefox-3 doesn't work for me neither :-( .
 I am on vista , calling autoconfig with all.js doesn't seem to do anything. I don't have errors, but nothing is "locked" and none of the displayError message I call with the setting of mine MOZILLA_DEBUG environement viriable works .
HEre's what I did;
1) ask all.js to call firefox.cfg

E:\Program Files\Mozilla Firefox-3\greprefs\all.js ends with

//Jehan autoconfig; http://developer.mozilla.org/en/docs/MCD,_Mission_Control_Desktop_AKA_AutoConfig
pref('general.config.obscure_value', 0);
pref('general.config.filename', 'firefox.cfg');

2) once irefox.cfg is called (which doesn't seem to occure :-( ) lock a default homepage:

E:\Program Files\Mozilla Firefox-3\firefox.cfg

//put everything in a try/catch
try {
// 1) env variables
if(getenv("USER") != "") {
   // *NIX settings
   var env_user = getenv("USER");
   var env_home = getenv("HOME");} else {
   // Windows settings
   var env_user = getenv("USERNAME");
   var env_home = getenv("HOMEPATH");}
  var env_mozdebug= getenv("MOZILLA_DEBUG");

if (env_mozdebug) {displayError("NO ERROR , just a test, user =" + env_user); }
lockPref("browser.startup.homepage", "http://www.it-sudparis.eu/" );
// Close the try, and call the catch()
} catch(e) {displayError("lockedPref", e);}

3) test it
E:\Program Files\Mozilla Firefox-3>set MOZILLA_DEBUG=1
E:\Program Files\Mozilla Firefox-3>set NSPR_LOG_MODULES=MCD:5
E:\Program Files\Mozilla Firefox-3>set NSPR_LOG_FILE=e:\tmp\ff3-log.txt
E:\Program Files\Mozilla Firefox-3>firefox

firefox shows up, but the default page is not set, nor the popup (which do work with thunderbird 2.0.0.14) of the displayError message doesn't shows up :-( .
Is there a kind of links to be done as it was mentionned on linux with autoconfig -> xulrunner ?
/usr/lib64/firefox-3.0/defaults/autoconfig -->
/usr/lib64/xulrunner-1.9/defaults/autoconfig
I don't see any xulrunner on windows firefox3 installation !?

any help, greatly appreciated .
Thanks .

It works, ;-)
it was a stupidity of mine, I had saved a copy of greprefs/all.js as filename all-copie.js and has it kept the .js extension is was read and probably overloaded the all.js calls .
now I have rename it to .old and these calls are well executed
pref('general.config.obscure_value', 0);
pref('general.config.filename', 'firefox.cfg');

So my lockPref("browser.startup.homepage", URL ); now works fine .
However I still cannot do ldap calls :-( , but that last since early realeses of firefox, cf
https://bugzilla.mozilla.org/show_bug.cgi?id=295329

Did exactly the same thing on a Vista box and it worked
so I copied the all.js and mozilla.cfg back to the XP box
and that now works - As far as I can see there was no
difference , but there must have been something. Creating
mozilla.cfg from scratch and using an old all.js and the
problem is back .. copy the vista ones and it goes away
so I guess it's not a bug ( just brain failure somewhere
)... whatever !

Moving to Mozilla Developer Center product.

The www.mozilla.org site should no longer host documentation. If there is still a need for this it should be added to MDC. Moving to Mozilla Developer Center product for discussion.

why MDC? isn't the proposed documentation for users? -> SUMO

david: feel free to veto :)

Hidden prefs are not for end-users. The docs is for developers and power users. Given that web developer docs are on MDC, I think it belongs there.

Marking as dupe of bug 330858.
Quick note about bug 330858: That bug has been ping ponged quite a bit from product to product; so please read the bug history and comments before moving it or resolving it.

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

chris: why the forward-dupe, in this case?

What is a "forward-dupe"?

you made this bug a duplicate of a bug that was opened later than this (the original) bug report. forward as in "forward in time".

That's where the issue of where this doc goes has been discussed/decided.

but this bug already had lots of blocks, depends ons, history, and even attachments. would you mind if i duped the other one here and we copied over any relevant info you find missing?

Okay, I'll switch it up.

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

This bug was reported using a version of Firefox that security and stability updates are no longer provided for. All users are strongly encouraged to upgrade to Firefox 3 by selecting 'Check for Updates' in the Help menu or by going to http://www.mozilla.com/en-US/firefox/firefox.html

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

If you can still reproduce this bug, please provide additional details to help resolve this issue.

this bug is revival in thunderbird 3.x and firefox 3.5 :-(

default Fedora11 packages needs to be recompiled with MOZ_LDAP_XPCOM=1
 and --enable-extensions=pref in order to beneficiate of that unvaluable feature (autoconfig based on ldap calls) for large enterprise deployements .

for details, check the doc I maintain at
https://developer.mozilla.org/index.php?title=en/MCD%2C_Mission_Control_Desktop_AKA_AutoConfig#Thunderbird

unfortunatly, this time, applying the usual compile options doesn't seem to be enough, although I recompiled thunderbird-3.0-2.3.beta2 with --enable-extensions=pref and MOZ_LDAP_XPCOM=1, when I start it with calls to a thunderbird defaultpref file within greprefs/all.js:
pref("general.config.obscure_value", 0); // for MCD .cfg files
pref('general.config.filename', 'thunderbird.cfg'); // for MCD .cfg files

at start-up, I get the following error message

"Netscape.cfg/AutoConfig failed. Please contact your system administrator.
 Error: getLDAPAttibutes failed: [Exception... "Component returned failure code: 0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsILDAPURL.spec]" nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)" location: "JS frame :: file:////usr/lib/thunderbird-3.0b2/defaults/autoconfig/prefcalls.js :: getLDAPAttributes :: line 174" data: no]"

looks as if the ldap extension for getLDAPAttributes function prefcalls.js isn't present !? or something else?. MOZ_LDAP_XPCOM=1 wasn't the solution to that ?

Any help, greatly appreciated .
thanks .

At Comment 26, Ben Bucksch wrote:-
Hidden prefs are not for end-users. The docs is for developers and power users.
Given that web developer docs are on MDC, I think it belongs there.

and at Comment 24 here and at comment 5 of Bug 330858, David Boswell wrote:-
The www.mozilla.org site should no longer host documentation. If there is
still a need for this it should be added to MDC. Moving to Mozilla Developer
Center product for discussion.

One has to ask "When does one move from beibg an end-users to a power user?" When one wants to make the program do something different to other users??

Somebody, somewhere (Mozilla Suite time frame I think) thought that an end-user (or maybe a "baby power user") might want to make particular changes to program operation, so allowed users to write preference alterations into a user.js file which was then incorporated into prefs.js when the program, Mozilla Suite, was run.

But NO WE CANNOT HAVE USERS MAKING CHANGES

Additionally, as we were/are told in the mozilla.support.seamonkey newsgroup, SeaMonkey Suite has been officially dropped by Mozilla, as far as development is concerned, and the code-base "given" to a volunteer group of programmers.

How are these volunteers, and others, to be able to do what they're supposed to do, development-wise, if they don't have access to the "complete" listing of the preferences??

(In reply to comment #35)
[...]
> How are these volunteers, and others, to be able to do what they're supposed to
> do, development-wise, if they don't have access to the "complete" listing of
> the preferences??

By trying to make sense out of the source, I suppose, which I don't think is very efficient performance-wise, or else by bugging "former Mozilla Suite devs" (gone over to Firefox now, maybe) with questions, which is even more annoying.

MDC is accessible by everyone. Target group is Mozilla devs, web developers and advanced users. If somebody edits users.js, he's an advanced user.
If you complain that there is no complete doc on MDC either, that's what this bug is about.