User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1 Several (but not every) add-ons save their preferences in prefs.js. If the add-on is removed or becomes obsolete, that <explitive deleted/> stays around until manually removed. IMNSHO, the user should NEVER have to manually edit prefs.js. RATHER, each add-on should have its own chrome:add-on-name/prefs.js [or some other name]. The startup process should then run thru the registry and call each such pref for the enabled add-ons. Against my own preference, I'm calling this ENH. It doesn't directly cause any failure - just a lot of inconvenience. Reproducible: Always

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

I respectfully disagree, even though they address the same sort of problem. I am recommending categorically that extensions NOT be allowed to change prefs.js; rather they should use a private preference script that can be either ignored or deleted.

Or at least, it should be possible to know what was the extension that had created the pref called. There was some toolbar of DXCurrencies kind that named its prefs "CT90438".

Someone who writes extensions -- Noscript is a serious offender, if the author is here he would be a good commenter. Would there be a serious difficulty keeping each extension's prefs in <profiledir>/<ext-uuid/prefs.js ? Then, as stated in the original description, having the base program load the prefs based on the current registry?

Some very useful extensions provide UIs for already existing preferences. The current consensus seems to be that extensions may store their own settings in prefs.js, but they should use preference names starting extensions.<name>. where <name> uniquely identifies the extension. This, however, seems to be more of a gentlemen's agreement than of a rigidly enforced rule. I don't think it's possible to enforce it in the light of the first paragraph of this comment. Having a different prefs.js for each extension would make it hard (if possible at all) to access extension-specific prefs via about:config if the extension's UI is not satisfactory. I suggest WONTFIX. Moving to Toolkit::Preferences but I hesitate between that and Core::Preferences:Backend.

The proposal here is currently impractical: we only have one place to store user prefs, and introducing multiple locations would be extremely confusing. In some future world this might be an interesting idea, but not in the forseeable future. WONTFIX.