FF - Manage Data / Remove All - Not working. Bug.
FF 66.0.3 (64-bit)
Cookie AutoDelete - I have checked "Localstorage Cleanup (Firefox 58+)?". But many sites remain - Cookies are deleted but storage persists. Or perhaps the Cookies listed are still there, even though it shows 0, because Data column still shows an amount.
In the developer's thread on GitHub, it is speculated that this is a FF issue:
"@pezz @planket2
I'm not sure how firefox displays the storage size completely, but based on my interpretation from the following screenshot, it's a firefox thing (or a bug on their end) and not a bug with this webextension itself."
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/512
NOTE - JUST DISCOVERED - It's even worse - FF definitely is not clearing Cookies and Data -
I've just done the following 3 times with the same result each time:
FF: Cookies and Site Data / Manage Data / Remove All - Everything disappears. I close it, then reopen manage data - they are all back, including ones for which I am not on their site currently (no tabs open) - such as
www.theguardian.com 0 48.0 kb 17 hours ago www.facebook.com 0 48.0 KB 2 days ago secure.agoda.com 0 96.0 KB yesterday
NOTE - Facebook.com from 2 days ago reappears, although no tab open on facebook.com, I"m using Cookie AutoDelete, Privacy Badger, uBlock Origin.
???
What to do?
All Replies (12)
"FF: Cookies and Site Data / Manage Data / Remove All - Everything disappears. I close it, then reopen manage data - they are all back, including ones for which I am not on their site currently (no tabs open)"
I made an error re: Firefox not clearing when I manually click "Remove All" - I didn't realize that after doing that I have to click "Save Changes". So all does get deleted when I do "Remove All" and then "Save Changes".
But the original problem is still there with Cookie AutoDelete not clearing some Cookies/Data, and github makes it clear they believe it is a FF bug.
Ti ṣàtúnṣe
Some of the storage shown in Manage Data dialog may not be data that is directly under the control of the website, and therefore the view from the website (or an extension inside that page) cannot see everything.
I don't have any current examples, but in the past I think one of my pages triggered storage of a huge volume of data (several megabytes) as a result of decompiling a WebAssembly or asm.js file to JavaScript. I guess Firefox figured it would avoid having to do it again by saving something there?
I should have looked at the issue thread first. So one possible remaining form of data is IndexedDB databases.
Thanks for the response.
I don't know what IndexedDB databases are?
Ti ṣàtúnṣe
IndexedDB databases are files that store data websites request Firefox to store in a database (it needs to be a specific request to use this type of file). To get an idea, you can use this demo page:
https://mdn.github.io/learning-area/javascript/apis/client-side-storage/indexeddb/notes/
After creating a couple of notes, open the Storage Inspector using Shift+F9. One of the categories in the left column will be IndexedDB and you can drill down in there to find the raw view of the database contents.
If you use the Manage Data dialog to clear data for mdn.github.io and then reload the demo page, your notes will be gone. However, it sounds as though the cookie/storage cleaner add-on might not clear that? You could test on this that page and see.
I just used twitter, closed the tab, and see this in "Manage Data...":
twitter.com 0 64.0kb
So it seems that twitter.com has had its Cookie erased but is still storing Data.
??
If it's a flaw with Cookie AutoDelete, how can I get FF to delete this automatically after I close the twitter.com tab?
I have "Delete cookies and site data when Firefox is closed" checked, so shouldn't FF have deleted the Twitter.com data?
Could I be causing a conflict by asking both FF and Cookie AutoDelete to get rid of it?
Ti ṣàtúnṣe
Twitter was a good example. Mine also shows 64 KB stored. And when I look in the storage folder on disk, I see a 64 KB caches.sqlite file (first screenshot). When I use a SQLite viewer web app to look inside, however, all of its tables are empty -- zero rows (second screenshot).
I don't know why Firefox kept the empty database when its contents were removed. Maybe to make it faster the next time I do something on the site that generates data needing to be stored in this file?? Anyway, it seems the Manage Data dialog can tell you how much disk space is being consumed by a site's storage files, but not whether those files contain any data.
There's a thread about this on github:
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/512?_pjax=%23js-repo-pjax-container
I discovered a bug on file (1401482) that probably explains why I have an empty caches.sqlite database for Twitter: using the Storage Inspector tool creates the empty database. (Screenshots attached.) That's annoying.
But whatever the reason for the empty caches.sqlite file in your case or mine, Firefox eventually needs some way to clean out these files in the background so they don't accumulate and clog up the Manage Cookies and Site Data dialog.
As mentioned, I have many of those "0 Cookies / [Storage size]" listed.
Are they all empty files?
Also, you can see from the Github thread that they feel it is a FF issue. Are you able to alert management/developers here?
Here's a better link for the Github thread (moved to here):
https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/issues/512
Ti ṣàtúnṣe
jscher2000 - Can you present this situation to the FF developers?
zzyzzk said
As mentioned, I have many of those "0 Cookies / [Storage size]" listed. Are they all empty files?
I don't know whether yours or mine are all empty files. It would take a lot of work to check each one. It is easier to just clear them if I think it's a site that should not be keeping any data stored in my Firefox.
zzyzzk said
jscher2000 - Can you present this situation to the FF developers?
Maybe I can do that later, but there are some bugs on file already so I would need to take time to understand what is in process already before filing something new.