Temporary-containers: LocalStorage isn't deleted

[grenzor]

Example: https://mdn.github.io/dom-examples/web-storage/

Set Temporary Containers to Automatic Mode, Reuse available numbers, setting Delete no longer needed Temporary Containers to after last tab closes in it
Visit above site (so it will open in a temp container) and edit some values and color around
Close the tab
Wait around a minute
Open Options -> Privacy -> Manage Data, storage is still stored for the site

Thought it might be something with my browser but I tried both FF beta+nightly and got the same result which makes me thinks it might be temporary containers (or general firefox containers) bug. It might even be doing this with cookies, indexedDB or other data also but I'm not sure. Although, it also seems odd when I visit the above site in a different temporary container than the first the values I changed aren't taking effect so it may be just a GUI bug in Manage Data and storage isn't really saved? Not sure what to make of this honestly.

[listalltabs]

Hi! Just another TC-0.87 user here! :)

I was looking at this, out of general interest, and starting with zero site data (in any container) for https://mdn.github.io

I made some notes as I was testing – on Nightly – and I can post them if needed, but here's the basic summary. (I'm not a developer or anything, so this is just based on observation, and could all be completely wrong!) :)

• Privacy -> Manage Data does not appear to recognise Local Storage for display purposes.

  • I believe Local Storage is held in $PROFILE/webappsstore.sqlite, but Manage Data only appears to display data under $PROFILE/storage/default. Manage Data does seem to delete all data for a site correctly; however, if the only data for a site is Local Storage, it won't appear under Manage Data in the first place and thus can't be deleted via it!
    .
• When a container is deleted – whether automatically (for Temporary containers) or manually (for MAC or other containers) – it does not appear to delete any of its data under $PROFILE/storage/default, which would minimally seem to include Indexed DB data.
  
  
  
  • Note that the mdn page in question would not normally create any data in this location; however, if you use the Dev Tools -> Storage Inspector to view the Local Storage that the mdn page does create, then the Inspector itself creates data under $PROFILE/storage/default, which Manage Data then recognises! So, when the container for the mdn page is deleted, its Local Storage may or may not be getting deleted; without delving into the webappsstore.sqlite database, before and after, it's difficult to tell! However, the data created by the Storage Inspector is definitely not deleted, and that is what is being reported, in my case anyway, by Manage Data! (Whether the data created by the Storage Inspector is intended behaviour, or not, is another question!) :)
  
  

[stoically]

Since the Temporary Container is correctly removed (with the one available API call for it, contextualIdentities.remove), this should be considered a Firefox Bug and reported on the Firefox Bugzilla: https://bugzilla.mozilla.org/ - if you do so, a link as reference would be appreciated.

It should also be noted, that even though the data might still be on disk, it should not be accessible at all since the Container ID is unique (in this case) and another Container without that ID should not be able to access that data.

[anewuser]

@grenzor @listalltabs Have you reported this to Mozilla?

[listalltabs]

@anewuser I haven't, no. I had a look on bugzilla to see if it was a known issue. Didn't seem to be – at least not directly – but I didn't have time to do an in-depth check. Feel free to file a bug if you have time yourself! Cheers! :)

[grenzor]

@anewuser I haven't filed a bug report there. Like listalltabs said feel free to file the bug report.

[anewuser]

@stoically https://bugzilla.mozilla.org/show_bug.cgi?id=1474608

[stoically]

Bug 1474608 was just marked as resolved with target milestone Firefox 73. Great stuff. Thanks for reporting @anewuser and staying persistent with those branch adjustments :smirk:

[geeknik]

I wasn't really monitoring this issue very closely, so I took a look and I had over 8000 (OMG) of those folders taking up space on my drive.. Hoping since I'm using Nightly this is really fixed now.

[stoically]

@geeknik would be great if you could let us know if it actually fixed it for you!

(oof, 8k)

[anewuser]

It seems that folders created on Firefox 73 are being deleted accordingly.

However, the fix won't delete folders created before this update, so you may want to delete them manually for the last time today.

[stoically]

In case someone is looking for a way to remove all orphaned containers, here's a bash script that can be executed inside the according $profile/storage/default directory. Warning: this is a destructive action that uses rm -rf, so, make backups.

#!/bin/bash
exclude=""
for id in $(jq '.identities | to_entries[] | .value.userContextId' ../../containers.json); do
  exclude="$id\|$exclude"
done;
exclude="${exclude}4294967295"
find . \
  -mindepth 1 \
  -maxdepth 1 \
  -type d \
  -regex ".*\^userContextId=[0-9]+\$" \
  -not -regex ".*\^userContextId=\($exclude\)\$" \
  -exec rm -vrf {} \;

Requires jq to parse the containers.json, on Ubuntu/Debian that's an apt install jq.