It seems the mechanism being used is a pref to "disable" the features of a system addon without actually disabling the addon itself. In an irc chat the other day with Jared Hirsch and Kris we suggested Jared move the pref based enable/disable handling out of the extension and into browser code. The next extension coming up, Firefox Monitor, is also using a pref for this purpose. We should just have a generic mechanism in the addon manager that knows how to manage this rather than having each extension do hacky things or add extension specific code to browser. straw man: use a pref tree: extensions.system.{extension.id}.enabled addonmanager users a pref observer on extensions.system, then enables or disables when the prefs switch.

note that IIUC Monitor will be pushed to existing releases, so we wont be able to do much there, but having a solid mechanism in place for the future is preferable.

(In reply to Shane Caraveo (:mixedpuppy) from comment #0) > straw man: > > use a pref tree: extensions.system.{extension.id}.enabled I don't think this helps since we have existing prefs (eg extensions.screenshots.disabled, extensions.pocket.enabled), we can't just rename them. Also the fact that screenshots chose to invert the pref (ie, true == disabled) makes a generic solution more trouble than its worth.

They can change their prefs and we can have a small bit of code to update to the new pref name. Not having a general mechanism translates into every future extension doing something funky, and leaving something running in all of them.

+1 from me. I'd be happy to change the pref for Screenshots. The only real work there would be making sure the policy engine is migrated correctly, plus updating the SUMO page.

Reverse scheme, please: extensions.system.enabled.<id> (In reply to Shane Caraveo (:mixedpuppy) from comment #3) > They can change their prefs and we can have a small bit of code to update to > the new pref name. Not having a general mechanism translates into every > future extension doing something funky, and leaving something running in all > of them. I'm cool with just ignoring the old preferences, unless someone has a major objection. Preferences that aren't exposed via some UI in general come with no warranties.

> I'm cool with just ignoring the old preferences, unless someone has a major objection Note that the screenshots preference is exposed to the policy engine

keeping higher on my radar

(In reply to Kris Maglione [:kmag] from comment #5) > Reverse scheme, please: > > extensions.system.enabled.<id> Can you elaborate on the advantages of this reversed scheme?