Closed Bug 851018 Opened 11 years ago Closed 11 years ago

Extension's data should be stored separately in its own directory

Categories

(Firefox :: General, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 915838

People

(Reporter: techlivezheng, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0
Build ID: 20130309010338



Actual results:

Currently, many extensions write its data in the top level of the profile directory, after having installed a lot of extensions, the profile directory became a mess, you can not easily tell which file was created by which extension. After uninstallation of some extensions, the data it stored in the profile directory is still there, and it is not easy to completely clear them.


Expected results:

There should be an sepecifc "Extension Data" folder which are used for extension's data storage, and each extension should store its data in a sub-directory named with its "ID".
Writing to the top level of the profile directory should be strictly limited. And this should be mandatory in a future release, and let the extension author have a transition time.

This way, the user created data can be easily managed.
Severity: normal → enhancement
OS: Linux → All
I am not sure anything should be changed in Firefox itself to solve this: for example, there is an SQlite editor, so Firefox cannot just prohibit writing outside of that directory.  Maybe a change in the addons.mozilla.org policy/recommendations would be enough.

The directory should be general to avoid difficulties like "config vs data" in the XDG Base Directory Specification (bug 259356).
Status: UNCONFIRMED → NEW
Component: Untriaged → General
Ever confirmed: true
See bug 915838 - it sounds like what you're asking for.
Hardware: x86 → All
Version: 19 Branch → unspecified
Depends on: 915838
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
No longer depends on: 915838
You need to log in before you can comment on or make changes to this bug.