User Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150806103657 Steps to reproduce: 1. start firefox -no-remote -profilemanager and create new profile "dummy" 2. start firefox with new profile 3. install mailvelope extension 4. close firefox 5. start firefox -no-remote -profilemanager again and delete profile "dummy", select [Delete all files] Actual results: Profile "dummy" not completely removed: - file jid1-AQqSMBYb0a8ADg@jetpack.xpi remains in subdirectory *.dummy\extensions\ - files cert8.db, key3.db, prefs.js, sessionstore.js, sessionCheckpoints.json, xulstore.json, parent.lock, content-prefs.sqlite, cookies.sqlite, formhistory.sqlite, healthreport.sqlite, permissions.sqlite, places.sqlite, webappsstore.sqlite and SiteSecurityServiceState.txt remain in directory *.dummy Expected results: ALL files and profile directory removed.
As it is happening because of the extension, this seems to go to extension compatibility.
QA Whiteboard: [testday-20150821]
Component: Untriaged → Extension Compatibility
I can only imagine this being an add-on issue if the add-on launches an external process that keeps the files open and blocks the Profile Manager from doing its job. I doubt that's the case, though.
If this issue is add-on specific then it could be related to our handling of the unload event. Currently the procedure is: - listen for sdk/system/unload - use "@mozilla.org/embedcomp/prompt-service;1" to ask the user if simple storage should be purged - if yes, clear simple storage
With WebExtensions being the only valid way of doing extensions in Firefox 57, I don't think this bug is still relevant.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 months ago
Resolution: --- → INVALID
If you don't support Firefox ESR 52 any more: DUMP IT, and post this in BIG RED letters everywhere you reference Firefox ESR!
You need to log in before you can comment on or make changes to this bug.