I'm working on an extension that uses the overlay-into-main-window,disable-with-pref strategy for a run-on-first-launch snippet. This is OK, except that I have to do a lot of manual work to track version numbers, etc. when I upgrade vs. uninstall/reinstall the extension. If there was a pref space "extensions.{guid}.*" that was purged when the extension was uninstalled, I think it would be easier for extension authors to be "well-behaved" about clearing their state on uninstall. Help me behave well!

OS->ALL At uninstalling a dialog is needed asking you if you want to just uninstall the extension or extension and prefs.

*** Bug 294515 has been marked as a duplicate of this bug. ***

Presumably this can only work if firefox knows what preferences an extension has set. Possibly using the preferences that an extension set defaults for is good enough?

I might want to uninstall an extension before installing a newer version. In this case I would probably want to keep the settings I made.

One problem with the "extensions.%GUID%.*" space is that you'd already have to take care of not interfering with the values used by the Extensions manager (name, description, etc. which are used for l10n). An alternative would have been to exclusively reservate some space for extension prefs (such as "extensions.%CHROME_NAME%.*" which would be more readable and still pretty unique - was it not for the fact that there are some browser specific prefs in "extensions.*" as well). With what we've got now, I'd probably go either with Dave's suggestion (probably with the restriction of not removing values also present in browser.js or other extensions' defaults) or with removing "extensions.%CHROME_NAME%.*" and/or "%CHROME_NAME%.*" (depending on which one exists) which might prove more successful with legacy extensions (in this case, the uninstallation dialog would probably have to offer an optional list of prefs to be deleted). A third alternative would be to let the extensions' authors indicate the branch to be deleted in install.rdf and update.rdf - which would solve the legacy problem in a somewhat safer way.

(In reply to comment #5) > A third > alternative would be to let the extensions' authors indicate the branch to be > deleted in install.rdf and update.rdf - which would solve the legacy problem in > a somewhat safer way. this would be the best solution. Perhaps something like: <em:prefSpace>extensions.linky</em:prefSpace> so when uninstalling linky the extension manager should ask the user: -------- Do you want to remove all extension related preferences (extensions.linky)? [yes] [no] --------

*** Bug 290875 has been marked as a duplicate of this bug. ***

maybe set the target milestone to Fx3? there's no way this would be included in Fx2. if it is considered at all, i suggest this be an option because as some have said, sometimes you want to keep them [the prefs] for future use and sometimes you just want to get rid of them entirely.

I'd prefer to keep this out of the install.rdf though there are still plenty of way to accomplish this while storing the data somewhere else. Perhaps an uninstall.rdf or better still a simple text list that is parsed on startup when an extension is uninstalled.

If the reason for this is to reset any options for the extension, then more than just preferences need to be reset. A number of extensions also use settings files or even whole folders in the user's profile directory. So if you're going to list somewhere all the prefs that should be reset on uninstall then why not include file names to be removed from the profile? I guess you probably want to do some intelligent filtering of a file list to avoid malicious extensions wiping important things. I'd suggest that an rdf file is overkill for this and a simple text file in the same vein as chrome.manifest would suffice.

I coulda sworn that I WONTFIXed this once. Just as we don't remove profiles when we uninstall Firefox we should not be removing extension-related prefs when the extension is uninstalled.

(In reply to comment #11) > I coulda sworn that I WONTFIXed this once. Just as we don't remove profiles > when we uninstall Firefox we should not be removing extension-related prefs > when the extension is uninstalled. As mentioned by comment #1 above, this should be optional. But it should be possible: if you get rid of SessionSaver or AdBlock or any other extension (mis-)using preferences for storing larger amounts of data, you shouldn't have to manually clean up prefs.js if you know that you won't need that data again. As for not removing profiles when uninstalling Firefox: is there a bug for that? This should IMHO be optionally possible as well - not that 50 MB of cache occupy much disk space, but what if every application left that much trash behind?

What Simon said, plus current behavior causes confusion for people who try to fix things up by uninstalling and reinstalling the app / extension. There was a thread on forums about this recently. I'm surprised it hasn't been mentioned already.

(In reply to comment #6) > this would be the best solution. Perhaps something like: > <em:prefSpace>extensions.linky</em:prefSpace> > so when uninstalling linky the extension manager should ask the user: > -------- > Do you want to remove all extension related preferences (extensions.linky)? > [yes] [no] Either ask or get rid of it completely. Another consideration would be to have individual preference files. That way, it would be easy enough to delete them after the fact.

If this were to be implemented I would prefer requiring any extension that would like this feature to use a specific pref location like extensions.GUID.* and just removing it on restart. If we want wider use of this it could be a requirement for any extension hosted on AMO to use this pref space. This would keep things extremely simple from an implementation perspective. I personally don't see a need to prompt the user for removal if this strategy were used since the pref space would be contained. This would of course mean that people that actually want to keep their old prefs would have to redo them but I would be very surprised if the number of times that is the case isn't extremely small.

(In reply to comment #15) What's the problem with adding a checkbox to the Uninstall extension dialog? If you implement this without asking the user, you'll just get the inverse RFE for allowing to keep the so marked preferences and probably hardly any author actually using the feature. Besides, using extensions.GUID.* is sub-optimal because some of these values are already used (for localizing the values in the Add-on manager) and that would make searching about:config more painful (for the not too uncommon case where an extension author asks a user to tell him which prefs are set or to toggle a hidden pref). Would adding an additional tag to index.rdf be that much more complex? I was going to suggest to at least allow an extension to add that checkbox - but that would obviously not work in safe mode. So why not add that checkbox per default (defaulting to unchecked) and if it's checked set a/add to the preference extensions.pref_branches_to_be_removed_at_startup (or so)? Should your only reason to oppose this be that you haven't got the time, I'll see whether I can implement this myself - but not without knowing what would be accepted.

My rationale for not having the checkbox is that I don't believe it is appropriate to add something else that the user has to think about. This is of course with the assumption that there are few people that uninstall then install the same extension and would want to retain the prefs. How do the values used for localizing come into play (e.g. nsIPrefLocalizedString from the extension's locale)? Why shouldn't the other non locale prefs used by the EM under extensions.GUID.* not be purged as well? The search issue is definitely valid. Some extension authors have previously provided bogus values and I'd prefer requiring a well known and contained location in order to prevent the author specifying a value they don't own.

(In reply to comment #17) > My rationale for not having the checkbox is that I don't believe it is > appropriate to add something else that the user has to think about. The argument for giving the user something to think in this case would probably be that most software uninstallations /don't/ remove the settings - at least not without further confirmation, such as to prevent dataloss. If we really don't want a checkbox, then I'd rather keep the prefs and hope for a clean-up extension which offers to purge prefs from previously installed extensions. > How do the values used for localizing come into play? They're something authors have to be aware of so that they don't accidentally overwrite them with internal values - and it might make it more difficult for you to add further values without risking to use some value already used. > Why shouldn't the other non locale prefs used by the EM under extensions.GUID.* not be purged as well? So far, there's nothing being purged here. The locale prefs just disappear because they're very rarely set to something other than the default value. > Some extension authors have previously provided bogus values and I'd prefer > requiring a well known and contained location in order to prevent the author > specifying a value they don't own. What about using the extension's (first) chrome namespace instead of the GUID (see my comment #5)? I don't know how difficult it'd be to figure that one out - but many extensions already seem to be following such a scheme. That would guarantee uniqueness while keeping searchability.

(In reply to comment #18) > The argument for giving the user something to think in this case would probably > be that most software uninstallations /don't/ remove the settings - at least > not without further confirmation, such as to prevent dataloss. If we really > don't want a checkbox, then I'd rather keep the prefs and hope for a clean-up > extension which offers to purge prefs from previously installed extensions. I suspect that you like many extension authors do uninstall / re-install. I do as well and would find this behavior a little annoying for myself. I doubt it would be annoying for most users though. I'm not completely against a checkbox but I am also not convinced that most users would get value from it. > They're something authors have to be aware of so that they don't accidentally > overwrite them with internal values - and it might make it more difficult for > you to add further values without risking to use some value already used. That is similar to why I dislike allowing the author to specify which prefs to remove on uninstall (e.g. assumption that it is ok to do something when we don't prevent them). At worst the problem would be contained to their extension. > So far, there's nothing being purged here. The locale prefs just disappear > because they're very rarely set to something other than the default value. Off the top of my head there is the extensions.GUID.update.enabled pref as well and the localized prefs will seldom if ever be modified by people using about:config. > What about using the extension's (first) chrome namespace instead of the GUID > (see my comment #5)? I don't know how difficult it'd be to figure that one out > - but many extensions already seem to be following such a scheme. That would > guarantee uniqueness while keeping searchability. As long as it is under extensions or a new root name to prevent potential collisions but using the chrome name has issues as well since there is no way to force uniqueness hence the introduction of the GUID - see bug 275054. For extensions using the name@tld format using the ID wouldn't be so bad. Perhaps if we also made it easier to convert to the name@tld format then using ID wouldn't be as bad for those that use about:config.

What are we actually trying to achieve here? If you want to remove settings for an extension so you can try it afresh or get Firefox working when an extension has messed something up then this solution won't cut it. Quite a few extensions change internal Firefox preferences, and I'd argue that it's more likely that these are the preferences causing problems. The original request talks about reducing the work of transitioning preferences from one version of an extension to another. It's a fairly trivial task to spot that your extension has been upgraded and wipe the prefs yourself, those you know you set, A bit more work (but far better) is to be able to transition properly, which if the EM wiped the prefs would be impossible. Also presumably the EM won't be wiping prefs on an upgrade only, so extensions would still have to manage the transition either way. Personally I'm for a WONTFIX on this. If people are having problems with an extension then ultimately it is a problem for the extension author.

I guess a checkbox for removing extension preferences would be nice (and a specification saying where the preferences should be stored so that they can be automatically removed). You could tell "uninstall extension X and check the checkbox to remove settings" instead of "remove all lines in prefs.js that contain X". I do not uninstall extensions often, especially now that extensions tend to upgrade smoothly. But it would be a poor design if EM deleted things behind my back without me asking.

(In reply to comment #16) > (In reply to comment #15) > > What's the problem with adding a checkbox to the Uninstall extension dialog? If > you implement this without asking the user, you'll just get the inverse RFE for > allowing to keep the so marked preferences and probably hardly any author > actually using the feature. (In reply to comment #17) > My rationale for not having the checkbox is that I don't believe it is > appropriate to add something else that the user has to think about. This is of > course with the assumption that there are few people that uninstall then > install the same extension and would want to retain the prefs. I am with post #17 in that it should be optional. Sometimes there is a "bad" extension which I don't want, and the preferences might also be corrupt. Better to just can it all in that case. In other cases, it might be better to leave preferences.

(In reply to comment #20) > What are we actually trying to achieve here? > > If you want to remove settings for an extension so you can try it afresh or get > Firefox working when an extension has messed something up then this solution > won't cut it. Quite a few extensions change internal Firefox preferences, and > I'd argue that it's more likely that these are the preferences causing > problems. Does Firefox provide a way to reset those to the "factory" default? If that could be done while leaving other extensions' extension specific prefs alone, that would be great. Again, a simple preferences file per extension would be best. I think back to the old Macintosh days when a program was in a folder and there was a prefs file there along with it. You could copy those prefs to other computers, back them up, etc. Sometimes there was even a program which validated prefs to make sure it WASN'T corrupt. Too bad we can't get a profile validator. Anyhow, there should be something for users to do which allows them to clear this junk out. Thanks for your work.

(In reply to comment #17) > My rationale for not having the checkbox is that I don't believe it is > appropriate to add something else that the user has to think about. > This is of > course with the assumption that there are few people that uninstall then > install the same extension and would want to retain the prefs. 1) At least at 1.5.0.*, it is still the case that authors often specify that users must uninstall extensions before installing new versions. Sometimes (rarely, now) this is because of changed GUID's. Users (_this_one_ for instance) certainly do not want to re-enter all their preferences for an extension every time this is done. 2) Whatever the claims about not needing to uninstall first, I still religiously uninstall before installing _any_ extension update. That may have reasons deep in history but I notice that I seem to be fortunate in not encountering any of the frequent horrid corruptions which other users _still_ frequently report, where most frequently it is clear that they have depended on 'on top' updating (ie without first uninstalling first). 3) I certainly do wish there was a mechanism to completely clear out all left-over data items from uninstalled extensions but that should not require any user, against their will, to re-enter any of their settings when extensions are _temporarily_ uninstalled. It seems that an implementation which required them to do so would do _far_ more to "add something else that the user has to think about" than making available a facility which was usable at, and only at, their discretion and at a time of their choosing. 4) The facility should operate in such a manner as to allow the user to control whether or not settings are removed. Possibly a global sweep facility would (?also?) be useful. On (and only on) user activation (by explicit user choice) it would clear out preferences of eligible format (only) for all extensions which were not currently installed. 5) "with the assumption that there are few people that uninstall then install the same extension and would want to retain the prefs". a) I don't know what evidence encouraged anyone to make that "assumption". I have made some points which make it quite likely that many users, if they correctly follow extension author instructions, frequently do just what is being discussed. b) My personal practical experience that it apparently really pays to always uninstall first and that it is still good practice for safety, leads me to suspect that I am not alone in following this. c) Yet again, my behaviour as a user (and I am not a developer or extension author) is apparently being second-guessed by some kind of would-be telepathy. Unless we actually have telepaths among us, could people please refrain from trying to use such totally unsubstantiated "top of the head" assertions about user behaviour to promote serious changes to things that will affect most if not all users to at least some extent and can actually harm many of us. Cordially, RDL

(In reply to comment #24) The right answer is not to just add ui for every possible choice and sometimes assumptions are often necessary especially since the majority of users aren't represented by the people in the forums or in bugzilla. I am not convinced that an option to not delete prefs is necessary but I am also not entirely against it as I stated. It would help if everyone - especially those that are active in the community / bugzilla - used the app as the majority of users do (e.g. don't uninstall due to fear of corruption) and if a a bug is found they reported it so the app can be improved. Dave, the original report from shaver is about cleaning up the prefs on uninstall which is what I am going on. I haven't heard of anyone having pref corruption with an extension though I haven't searched bugzilla for such a report so I don't think it has anything to do with that. There is the case where people enter incorrect data in about:config which I suspect is considered corruption by some and there is also the case where a couple of extensions have chosen to store data in prefs that should IMO be stored in a separate file. Both of those cases should be handled separately IMO and is not what I am discussing. Personally I see this as a nice to have but I doubt the average user would benefit either way from this.

(In reply to comment #25) > (In reply to comment #24) > The right answer is not to just add ui for every possible choice But it definitely _is_ the right answer to add ui for every _common_, _reasonable and _probable_ choice, especially where doing so will very significantly reduce end-user effort and frustration and even more so where it will add to end-user safety without simultaneously nailing down their hands. This is certainly such a case. I have seen many end-users arriving on forums with problems relating to failed 'on top' upgrades to extensions and having those problems quickly cleared by someone's advice to unistall the original version before attempting to install the update. About half the time that advice comes from the extension author. In fact, decent designers are always stretching themselves and their imaginations to try to sensibly imagine what choices their users might reasonably (primarily from the user's point of view, and only secondarily from that of the the designer) need. They will often go out and about, asking their end-users to try the product, or at least the idea of it, and provide reactions. User support is not correctly performed by someone who is always defending restrictive and inflexible positions which remove resilience, comfort and safety from the user, even if the support agent rather half-heartedly professes to being open to flexibility. The art is to make the defaults work correctly and comfortably in most situations for most users without removing/barring additional helpful options. > and sometimes assumptions are often necessary Why assumptions? How about research? Such as, for instance, listening to user feedback, when it is provided, and simply hearing it instead of pushing it aside? What do you think is the function of prototyping? Do you ever _watch_ a wide range your user types working with the product and discuss with them their resulting experiences and reactions? > especially since the majority of users aren't > represented by the people in the forums or in bugzilla. Users contribute to forums either because they need help or because they want to provide it (and often, at one time or another, for both reasons). You suggest that until someone seeks help for the first time they are so different from themselves after the event that they, and their interests, were up to that point unrepresented. Everyone on those forums is a user. Of these, a few are also producers. Many others are relatively inexperienced and are only there because they have hit problems. > It would help if everyone - especially those that are active in > the community / bugzilla - used the app as the majority of users do (e.g. don't uninstall due to fear of corruption) Yes, wouldn't it? Then, just like less experienced users, _all_ of us could suffer the same problems over and over again without acquiring the knowledge and skills to avoid them and those who wanted help wouldn't need to look for it because it wouldn't be there. We're not here talking about "clever-clever" tricks but just about learned advantageous behaviour. > and if a a bug is found they reported it so the app can be improved. This particular example among best updating practices is already well known, has been frequently reported in many different places, by and to many different people. (Thankfully, it it one of those which have largely superceded the once frequent "delete your entire profile and rebuild it"). Bug reports in some form or other have been submitted to authors and they may have acted, if only to state that the technique required is as here discussed. Like certain other related and less related problems, it's an old chestnut. In fact the people who put some effort into helping in forums more often than not put a great deal of time into torturing selected extensions/host releases in any way they can imagine, both typical for themselves and also simply possible for any unknown, unpredictable and possibly distracted user. They then sit up for hours submitting constructive and systematic bug reports to the authors concerned. As for "the majority of users", please see "normal distribution curve". There is no _single_ "typical" mode of behaviour. No-one whom I know has 1.5 children, and there is _no_such_thing_ as an "average" user about whom one may speculate or make assertions. RDL

*** Bug 343489 has been marked as a duplicate of this bug. ***

*** Bug 358564 has been marked as a duplicate of this bug. ***

There is a possible solution to this that I have not seen mentioned in the discussion. There could be a bit of js that the extension developer registers with the EM. Upon the uninstall of the extension, this could be called so that the extension developer could clear out any preferences, any data files and anything else besides. One could continue to try to guess what developers will want. Is that productive? We could, instead, give the tool to the developer just the once. I bet there are some other long-standing and contentious bugs that could be closed from adding this capability.

(In reply to comment #29) > There is a possible solution to this that I have not seen mentioned in the > discussion. There could be a bit of js that the extension developer registers > with the EM. Upon the uninstall of the extension, this could be called so that > the extension developer could clear out any preferences, any data files and > anything else besides. > > One could continue to try to guess what developers will want. Is that > productive? We could, instead, give the tool to the developer just the once. Just giving the responsibilty to the extension developers doesn't help anyhow IMHO. This would be similar to what MS does with the registry which ultimately leads to a system full of unused preferences. An alternative to this offload would be IMHO to just add a switch whether to remove preferences or not on extension's removal. Therefore FF would be responsible for keeping itself clean which is better than forcing possible inexperienced and/or unwilling extension developers to do such things.

If we are going to assume that extension developers are ignorant or willfully hostile to the app, that is a different problem. Solutions to that might including enforcing a secure per-extension memory model, but these kinds of questions are not part of the current question. Do we have a way to allow extension developers to do the right thing if they want to do the right thing and are willing to educate themselves on how to do this? The answer right now seems to be no. Is there a way to allow extension developers to do the right thing if they want to do the right thing and are willing to educate themselves on how to do this? Yes. I think I have proposed it. Assuming extensions to be, in general, hostile would probably lead to a much different Firefox.

(In reply to comment #31) > Do we have a way to allow extension developers to do the right thing if they > want to do the right thing and are willing to educate themselves on how to do > this? The answer right now seems to be no. > > Is there a way to allow extension developers to do the right thing if they want > to do the right thing and are willing to educate themselves on how to do this? > Yes. I think I have proposed it. http://developer.mozilla.org/en/docs/FUEL:Extension https://bugzilla.mozilla.org/show_bug.cgi?id=340339#c7 Needs the disabled/enabled stuff too (enabled will be harder), patches very welcome, over in that bug.

I filed another bug a while back requesting that extensions not "pollute" the shared prefs.js file. If and when I locate that one, it can be flagged a duplicate of this. If each extension is given its own prefs file, presumably in its own directory, there would be no need to "wipe" anything. The startup logic should simply read/run only the prefs for REGISTERED extensions. If an extension is out-of-date or otherwise disabled the prefs would not need to go away -- they simply wouldn't be acted on. It looks so simple. What am I missing?

David, how would you know what pref file to write each preference to (from calls to nsIPrefBranch)? And what do you do if there's a userpref set in multiple files, as well as the canonical userpref file (prefs.js)?

Well, this is my idea. These should be the priorities: 1) prefs.js 2) prefsExtensions.js 2) extension pref files 3) firefox.js (it exists yet?) 4) user.js In prefsExtensions.js Fx will store all global settings that extension would add or modify (that is: prefs different by extension.ExtName "classic" prefs) In one extension pref file, Fx will store settings that the extension want to use only for itself (extension.ExtName prefs) Those prefs should _not_ be written in pref.js, unlike user.js prefs. In about:config, pref.js and extension prefs should be all shown. If prefsExtensions.js overrides a pref, it should be displayed in a different way (another colour, or italic, or highlighted, ...). If the user will change one of those prefs in about:config, the change will be stored in prefsExtensions.js. If an extension pref will be changed, it will be stored in the related extension pref file. In this way you can remove easily extension prefs, and track global pref modification made by extensions.

I'm not an extension developer yet so I might sound naive, but adding splitting user preferences over several different files sounds rather nasty, especially as all current extensions don't expect this to be the case. Surely, if all extension-specific prefs are stored under extensions.extname.* then Firefox can intelligently delete the entire pref list under that name when an extension is uninstalled. If FF handles it, then the developer doesn't need to, which is a plus, and it also means you don't need to worry about cases like uninstalling a disabled extension.

(In reply to comment #36) > I'm not an extension developer yet so I might sound naive, but adding > splitting user preferences over several different files sounds rather nasty, > especially as all current extensions don't expect this to be the case. I think this is not a problem, it is Firefox that read and writes prefs, not extensions. For example, if pref.js change name (I hope) extensions must _not_ be rewritten :-) > Surely, if all extension-specific prefs are stored under extensions.extname.* > then Firefox can intelligently delete the entire pref list under that name > when an extension is uninstalled. Since the extname is arbitrary, this can be done only for new extensions. Furthermore it doesn't solve the problem of Fx prefs changed by extensions.

> Furthermore it doesn't solve the problem of Fx prefs changed by extensions. True... I would hope that there was some standard way to revert settings on uninstall, then, that doesn't necessarily require the extension to run a script. Something like an uninstall manifest. I guess it would have been nice if the system was originally designed to have global and extension pref spaces.

The preferences should also be removed when starting in safe mode.

(In reply to comment #40) > The preferences should also be removed when starting in safe mode. With the currently proposed solution, the prefs would never be loaded in the first place when loading in Safe Mode, so everything stays tidy.

(In reply to comment #41) > With the currently proposed solution, the prefs would never be loaded in the > first place when loading in Safe Mode, so everything stays tidy. Not sure what the currently proposed solution is, if you mean either comment 35 then for it to really work extension authors would have to use a different interface that method for storing preferences than that that they currently use. That would be the only real way to know to save their preferences to a different file. This alone I believe makes the solution very problematic. There is so much documentation out there on the current prefs system that getting authors to change would be a very long road. As well as this the solution doesn't seem to cope with multiple extensions and the application using the same preference, which setting wins?

(In reply to comment #42) > if you mean either comment 35 then for it to really work extension authors > would have to use a different interface This is true, but you can also modify the current interface. 'Simply' Fx create a small SQlite database of all "official" prefs. If an extension want to store a pref using the "old" XPCOM component, if the pref is one of "official" ones it's stored in prefsExtensions.js. If it's not, it's stored in a pref file into the extension folder, and the "redirect" is stored in extensions.rdf. So if the extension wants to read an "unofficial" pref, it will be "redirected" to that file. > this solution doesn't seem to cope with multiple extensions and the > application using the same preference It can be done in prefsExtensions.js. A pref can end with date it was added/last modifed (year-month-day-hour-minute-seconds-milliseconds) and with the ext GUID. Example: browser.chrome.site_icons.20080611164135760.{5e594888-3e8e-47da-b2c6-b0b545112f84} Anyway I think it's less important than the separation of Fx and extensions prefs.

(In reply to comment #43) > (In reply to comment #42) > > if you mean either comment 35 then for it to really work extension authors > > would have to use a different interface > > This is true, but you can also modify the current interface. 'Simply' Fx create > a small SQlite database of all "official" prefs. If an extension want to store > a pref using the "old" XPCOM component, if the pref is one of "official" ones > it's stored in prefsExtensions.js. If it's not, it's stored in a pref file into > the extension folder, and the "redirect" is stored in extensions.rdf. So if the > extension wants to read an "unofficial" pref, it will be "redirected" to that > file. This still requires extension authors to use a different interface. For all this to work the preferences system needs to know what extension is trying to set a given preference. The only way for that to work realistically is for the extension to pass it's guid with the pref set (or init a pref branch including the guid or so). > Anyway I think it's less important than the separation of Fx and extensions > prefs. This makes me wonder what the actual goal of this bug is. If all we want to do is clear an extension's private preference branch, then that is simple, just a few lines of code. I don't believe there is much point in implementing that though since extensions frequently set preferences outside of their own preference branch, it is actually those that are more problematic after uninstall, non-standard prefs are just ignored. Even then wiping preferences does not mean an extension's settings have gone away, there are settings files in profiles, logins in the password manager, all of which would need to be removed in order to truly remove an extension's settings.

(In reply to comment #44) > This still requires extension authors to use a different interface. For all > this to work the preferences system needs to know what extension is trying to > set a given preference. The only way for that to work realistically is for the > extension to pass it's guid with the pref set (or init a pref branch including > the guid or so). Mmmh... Fx can't retrive in some way theext GUID, knowing the function that called get and set*Pref? > This makes me wonder what the actual goal of this bug is. [...] I don't > believe there is much point in implementing that though since extensions > frequently set preferences outside of their own preference branch, it is > actually those that are more problematic after uninstall It's true. I think the method I proposed in Comment 43 should solve this. If the extension is removed, all preferences with its GUID are removed. If a pref is read and more than one extension have modified it, the latest is taken. > Even then wiping preferences does not mean an extension's settings have gone > away, there are settings files in profiles, logins in the password manager, > all of which would need to be removed in order to truly remove an extension's > settings. Well, this is another problem. I don't think they cause much trouble, as non-standard prefs. Anyway they can be treated as non-standard prefs, that is put files in an extension subfolder and passwords in a signonsX.txt file into the same subfolder.

I think the issues with extensions modifying core preferences is beyond the scope of this bug. As far as I can see, the simplest way to sort this out is to make a new pair of functions for getting and setting preferences tied specifically to an extension, such as setExtensionPref('name', 'value') which actually creates a preference under extensions.GUID.name; when the extension is uninstalled, any preferences found under that GUID will be removed automatically. This doesn't fix current extensions, but it should work with new ones, and those that choose to update their code. I don't think there's much else we can do. Or... You can keep track of every setting an extension adds/changes over its lifetime and rollback. Does XPCOM know who called it?

WONTFIX per comment 11

(In reply to comment #11) > I coulda sworn that I WONTFIXed this once. Just as we don't remove profiles > when we uninstall Firefox we should not be removing extension-related prefs > when the extension is uninstalled. I think the problem is not an uninstaller, or the additional data as Dave Townsend wrote in Comment 44. The problem is to track changes made by extension to Fx prefs. If Fx will separate changes to pref made by extensions and changes made by users, it will be more simple to reset bad modification. And if Fx will also track which extension has done one changes, you can also see what extension has caused the problem. An uninstall GUI is secondary. What matters is a good tracker, so I can see who made what. Currently the Firefox preferences system reminds me Windows registry one too much. (Anyway, I must say that Fx uninstallation could remove profile(s) if an user wants so. It's important because they are sensible data. It's not very uncommon for uninstallers)

(In reply to comment #47) > WONTFIX per comment 11 > (In reply to comment #11) > I coulda sworn that I WONTFIXed this once. Just as we don't remove profiles > when we uninstall Firefox we should not be removing extension-related prefs > when the extension is uninstalled. I don't know for release builds, but I noticed you can remove profiles in Trunk uninstallation: http://www.fileden.com/files/2007/8/9/1334417/fx3-uninstaller.png I think this bug can be reopened.

From comment#25: "and if a a bug is found they reported it so the app can be improved." <sarcasm>Right!</sarcasm> so someone can make it "WONTFIX" Reasonable minds may disagree, of course, about what constitutes an improvement. One thing I would note: we have (I hope) many more users than extensions developers. And YES, those extensions that add huge cruft to prefs.js should be encouraged to put them elsewhere. Perhaps someone could experiment with the approach mentioned in Comment#43. And, perhaps, we should take the whole discussion over to the wiki.

Please don't start a flame. An user is free to suggest something as a developer is free to say 'no'.

Reopening for what I wrote in Comment #49

Please don't reopen this bug.

Excuse me Smedberg, but have you read what I wrote in Comment #49?

Yes and it's basically unrelated to this bug. If you uninstall Firefox and remove your settings, the extension settings will be removed as well.

(In reply to comment #51) > Please don't start a flame. An user is free to suggest something as a developer > is free to say 'no'. > Honestly, I'm not trying to start a flame-war. But the recent back-and-forth just cuts off a meaningful debate. And it is quite frustrating! Re: Comment #56: A less drastic proposal would be stating with a clean profile. It's also a pain, because then one must add back in all desired extensions. But it would get to the "right" state. If you just suggest "uninstall Firefox and remove your settings." you may be just asking to do without one more pesky user. Again, taking the question(s) about the extensions framework over onto the wiki might just be less contentious than doing this in the context of a "bug." But, hey, I'm just another user and sometime informal tester. And this is far from the most irritating burr under my seat.

(In reply to comment #57) > Re: Comment #56: [cut] As Smedberg said, and I think so, this bug is unrelated to Firefox uninstall options. And this is the reason why I don't understand the wontfix motive......

Who cares? It's only bloat! Firefox does load all of this unused extension crap into memory, so there should be a way to remove it without having to manually edit the config files!