594462 - The Jetpack SDK should reset the prefs made by a jetpack when it's disabled/uninstalled

Status: RESOLVED WONTFIX

(Add-on SDK Graveyard :: General, defect)

Description

[(no longer active)]

I wrote an extension whose entire purpose was to flip a pref, like this:

exports.main = function(options, callback) {
  require("preferences-service").set("keyword.URL",
    "http://www.google.com/search?ie=UTF-8&oe=UTF-8&sourceid=navclient&gfns=1&q=");
};

And I just assumed that when the extension is disabled or uninstalled, the value of this pref is reset, but this is not the case.

Comment 1

[Brian King [:kinger]]

Some add-on authors like their pref values to hang around in case of reinstall/reenable.

Comment 2

[(no longer active)]

(In reply to comment #1)
> Some add-on authors like their pref values to hang around in case of
> reinstall/reenable.

That, if desired, should not be what happens by default.

Comment 3

[Erik Vold]

It's not difficult for an addon author to save a pref b4 changing it, store it, and then flip it back on uninstall, w/ jetpack-core modules, although building this in as an option for addon authors to use seems like a good idea to me. For some default prefs, it is a public status requirement for addons at AMO when they change a default pref that the pref should be changed back when the addon in removed.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

The Add-on SDK is no longer a Mozilla Labs experiment and has become a big enough project to warrant its own Bugzilla product, so the "Add-on SDK" product has been created for it, and I am moving its bugs to that product.

To filter bugmail related to this change, filter on the word "looptid".

Comment 5

[Myk Melez [:myk] [@mykmelez]]

Addons that set their own preferences should do so by storing them via the Simple Storage API, in which case they'll be removed when the addon is uninstalled.  And when we provide them with a high-level Preferences API (which is built on top of Simple Storage), that API should also do that automatically.

But it's really tricky to figure out which changes addons make to browser preferences and how to undo them.  There are many edge cases.  And browser preferences are not the right place for most addons to be making changes anyway (which is why the preferences-service API is a low-level module targeted to API developers, not addon developers).

So this seems like something that folks using that service should implement themselves on top of it.

Comment 6

[Drew Willcoxon :adw]

(In reply to comment #5)
> Addons that set their own preferences should do so by storing them via the
> Simple Storage API, in which case they'll be removed when the addon is
> uninstalled.

(Except for bug 627432.)

Comment 7

[(no longer active)]

I think it's a good idea to get this best practice of using the Simple Storage API documented somewhere, as it's not immediately obvious.

Comment 8

[Drew Willcoxon :adw]

We tell people that addon-kit (which includes simple-storage) is for add-on devs and api-utils (which includes preferences-service) is for people writing APIs but no one believes us.

Comment 9

[Dietrich Ayala (:dietrich)]

We should fix this for 1.0 IMO, whether it's via documentation of using Simple Storage for prefs, or by building the high-level API Myk describes.

Re-opening to get more discussion on this.

Comment 10

[Myk Melez [:myk] [@mykmelez]]

(In reply to comment #9)
> We should fix this for 1.0 IMO, whether it's via documentation of using Simple
> Storage for prefs, or by building the high-level API Myk describes.

Yes, I agree, we should do both those things, ideally for 1.0, although it isn't clear whether we'll have the time/people to implement a Preferences API by then.


> Re-opening to get more discussion on this.

I would prefer to track each discreet task in its own bug, so the record is clear about what we decided to do (and not to do).  I have filed bug 645207 on implementation of a Preferences API and bug 645209 on clarifying the situation in the documentation.

Does this seem reasonable?

Comment 11

[Dietrich Ayala (:dietrich)]

(In reply to comment #10)
> > Re-opening to get more discussion on this.
> 
> I would prefer to track each discreet task in its own bug, so the record is
> clear about what we decided to do (and not to do).  I have filed bug 645207 on
> implementation of a Preferences API and bug 645209 on clarifying the situation
> in the documentation.
> 
> Does this seem reasonable?

Yup! closing.