> 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?
> The document www.mozilla. org/catalog/ end-user/ customizing/ briefprefs. html pref/all. js on a Windows installation of Firefox 1.0
> http://
> 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/
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 config. filename" default to a file that
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.
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?