User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:37.0) Gecko/20100101 Firefox/37.0 Build ID: 20141205161135 Steps to reproduce: Related to https://bugzilla.mozilla.org/show_bug.cgi?id=1108264 , I couldn't see an obvious way for a user to remove persistent data for an add-on. In Chrome, removing an add-on also removes all of its data, including IndexedDB databases. This seems intuitive to me since the behavior is the same for apps on iPhone for example. In Firefox, removing the add-on leaves the data around in storage/default/persistent. The result is that if the IndexedDB database becomes corrupt, either due to system or browser issues like 1108264 or an app-level issue where the add-on gets data in the IndexedDB into a state which it cannot handle, there is no easy way for a user to reset the add-on. Actual results: Removing an add-on leaves its local data intact Expected results: Removing an add-on should remove the persistent data, or there should at least be some alternative mechanism invokable via the UI that achieves the same effect.

The security model for traditional add-ons is essentially "do what you like" - so they can read/write arbitrary files on the disk (within the limits of the regular OS permissions that Firefox and/or the user running it has). While I'm not familiar with iOS, this would be similar to e.g. Android apps storing data somewhere on the SD card - Android won't remove the extra stored data if you remove the app. Similarly, it's therefore almost impossible (without significant rearchitecturing) to solve this in the general case. If you're asking for indexeddb only, that might be possible, but there too, aren't add-ons able to store data under the browser window's database (related to chrome://browser/content/browser.xul) rather than their own modules? In which case, how would we distinguish that?

@Gijs You're right about the general case for 'traditional' add-ons. I'm writing a Jetpack add-on though using the add-on SDK APIs exclusively (code and overview at http://robertknight.github.io/passcards/) which doesn't need to access local data outside of per-add on private storage. Like most mobile apps and some extensions, the local data is a basically a cache of data stored in the cloud for performance and offline use. For modern Jetpack addons, it should be possible to clear at least the extension-specific data folders (IndexedDB, localStorage etc.) when the extension is removed. iOS apps and Chrome extensions both have containers for user data which is wiped when the app is removed. That solves the main problem outlined in my original report where problematic local data (created by the app itself, or a bug in the OS, or data corruption caused by something else) can be fixed easily by the user be removing and re-installing the app/extension.

(In reply to :Gijs from comment #1) > Similarly, it's therefore almost impossible (without significant > rearchitecturing) to solve this in the general case. And yet we have done that! Marking WONTFIX for the cases of legacy bootstrap and SDK extensions.