347609 - Officially reserve 'extension.' pref branch for extensions

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, enhancement)

Description

[Jez]

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 'flashgot.foo' 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

Comment 1

[Dave Townsend [:mossop]]

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.

Comment 2

[Robert Strong (they/them - no direct email)]

What value will doing this provide?

Comment 3

[Jez]

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.

Comment 4

[Robert Strong (they/them - no direct email)]

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.

Comment 5

[Robert Strong (they/them - no direct email)]

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.