When deploying Moz for a (large-)number of users/workstations, its possible to give users a basic "template" prefs.js. However, when something system-wide changes, the only way to get Moz to notice this change is to push a new prefs.js onto the users which implies that user personal settings get lost. Might it be possible to have Mozilla look for "pre-" and "post-" prefs files when loading prefs? The 'pre-' prefs file would contain default settings, but are overridable by the user's own prefs.js (if the user decides to change them) In other words, these would be defaults that supercede Moz's built-in defaults. The 'post-' prefs file would contain settings that overrule prefs.js, proxy settings for example. It would be nice if the postload options were treated as 'read-only' in the sense that they wouldn't be present in the preferences dialog, but this is not strictly necessary (only wishful thinking). Perhaps these two files could be automatically searched for in some subdirectory under the Mozilla installation (mozilla.org/default_prefs/ for example).
The "pre-" files already exist -- all.js (loaded on all platforms), unix.js, macprefs.js, etc Confirming rfe to add the "post-" files.
Assignee: Matti → bnesse
Status: UNCONFIRMED → NEW
Component: Browser-General → Preferences: Backend
Ever confirmed: true
QA Contact: imajes-qa → sairuh
The post- also exists in the form(s) of user.js - user editable prefs which override prefs.js netscape.cfg - Non editable preferences set with the CCK tool which override everything. Not really INVALID, bug ALREADY_IMPLEMENTED isn't a resolution. :)
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → INVALID
In which directory can I put the all.js, user.js and netscape.cfg ? Do all these follow the user_pref("foo",1) method for setting options?
er, never mind. I've figured out how all.js and user.js work. Thanks.
mass-verification of Invalid bugs. if you don't think the report is invalid, please check to see if it has already been reported (it might be a duplicate instead). otherwise, make sure that there are steps (a valid test case) that clearly display the issue as an unexpected defect. mail filter string for bugspam: SequoiadendronGiganteum
Status: RESOLVED → VERIFIED
[RFE] is deprecated in favor of severity: enhancement. They have the same meaning.
Severity: normal → enhancement
You need to log in before you can comment on or make changes to this bug.