Officially reserve 'extension.' pref branch for extensions




12 years ago
10 years ago


(Reporter: bugzilla, Unassigned)


Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1b1) Gecko/20060710 Firefox/2.0b1

Although it is currently recommended that extensions put all their own prefs into the 'extensions.' pref branch, it doesn't seems to be officially reserved from Firefox's own prefs.  Whatsmore, not all extensions currently do this (eg. Flashgot just uses '' for most of its prefs).

As I'm told that Firefox stores some of its own prefs under 'extensions.', I propose we lop off the 's' and reserve the 'extension.' branch for the prefs used solely by extensions.  I've checked, and no Firefox prefs seem to be in there already, so it should be fine to reserve.  There should never be any official browser prefs under the 'extension.' branch, and that should be enshrined in code somewhere.  Then we should advise extension writers to put all their extension's own prefs in 'extension.{prefID}.whatever'.

Reproducible: Always
Note that toolkit apps already use the extensions.<extensionid> space for extension localisation purposes and the extension's etiquette guide advises using the extensions.<extension name> pref branch.

Personally I don't believe that there is a need to reserve a pref branch.

Not really sure where this needs to go since every toolkit app would need to abide by this, including the core gecko. Since it's extension related though it's probably best to start there.
Component: Preferences → Extension/Theme Manager
QA Contact: preferences → extension.manager
What value will doing this provide?

Comment 3

12 years ago
I'm just trying to think of a way to make prefs more organised.  I don't really like the fact that extensions can create prefs like flashgot.altClick.

If you think about it, extensions have the same privileges as browser code (chrome) yet aren't under the same scrutiny.  A change to the browser that tried to create a pref with the wrong identifier would be fixed by peer review, but extensions can come along and spray them wherever they want.  I'm not sure there's a good way to stop it, however.
If you are suggesting we recommend that extension prefs only live under "extensions." and we move em prefs out from under "extensions." then this could easily be done as part of the extension manager. If you are suggesting that we prevent extensions from setting any prefs outside of "extensions." then that would need to be done outside of the extension manager.

Either way, I don't know of any real world examples where this would provide value and the amount of work to value ration (e.g. pain to gain) is huge, extensions would still need to set prefs outside of "extensions.", and I am sure there are a bunch of other issues besides those two.
This is little different than an extension adding tons of ui that many people would find annoying and the app doesn't prevent that even though that is clearly visible to the end user. I see little value in adding this especially in comparison to the amount of work it would take to sandbox a pref branch. I would reconsider if there is a real world example where this would provide value greater than the work / overhead it would take to add this and if there is a bug open and accepted by the module owner for the pref system where the vast majority of this work would need to be done.
Last Resolved: 12 years ago
Resolution: --- → WONTFIX


10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.