Same for me, and to make it more exciting about:newtab creates an SQLite database. I'm not sure if this is still the case, but a couple of months ago I had thousands of these newtab databases lying around, each 5Mb, which ate a decently large chunk of my hard drive.

I've been using a small shell script to manually delete these files, but that's fragile, especially since extension data got moved to the same folder.

function clean-firefox-containers -d "Removes storage from old temporary containers"
  set -l storage_dir ~/Library/Application\ Support/Firefox/Profiles/*.default/storage/default

  find $storage_dir -name "http*^userContextId=????*" | xargs rm -r
  find $storage_dir -name "about+newtab^userContextId=*" | xargs rm -r
end

Max, I no longer feel alone in this world. I've lost my extensions settings because of a similar PowerShell script I've been using since I opened this issue. Here's the fixed version:

Get-ChildItem -path "C:\Users\123\AppData\Roaming\Mozilla\Firefox\Profiles\123\storage\default" | Where{$_.Name -Match "userContextId|instagram|gazeta|github.io|globo|googleusercontent|yandex"} | Where{$_.Name -NotMatch "moz-"} | Remove-Item -Recurse

I'm adding some domains manually too because another Firefox limitation prevents Cookie AutoDelete from deleting some kind of storage created by tabs not in containers (IndexedDB, I think).

Maybe janv knows more about what is happening here.
When a container is removed, we call: Services.clearData.deleteDataFromOriginAttributesPattern({ userContextId });
https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/toolkit/components/contextualidentity/ContextualIdentityService.jsm#298

Why do we still have container-related folders in the user profile directory?

I think changes by Tom and Jan here to origin clearing in 68 should cause these directories to be removed, but redirecting to Tom to confirm and/or further analysis.

(In reply to Andrea Marchesini [:baku] from comment #6)

When a container is removed, we call: Services.clearData.deleteDataFromOriginAttributesPattern({ userContextId });
https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/toolkit/components/contextualidentity/ContextualIdentityService.jsm#298

This should be observed by QMS [1], IIUC.

While trying to reproduce the issue, I found QMS didn't receive the message. I wonder if it hasn't been initialized/registered or something else so that it didn't propagate the message to the QM. I'll look into it more.

[1] https://searchfox.org/mozilla-central/rev/6c9f60f8cc064a1005cd8141ecd526578ae9da7a/dom/quota/QuotaManagerService.cpp#791

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #7)

I think changes by Tom and Jan here to origin clearing in 68 should cause these directories to be removed, but redirecting to Tom to confirm and/or further analysis.

Yes, that's https://bugzilla.mozilla.org/show_bug.cgi?id=1529122. If the folder is empty, it would be removed in 68.

See also bug 1537882. The category entry doesn't work there too.

Depends on D33758

Depends on D34324

Depends on D33758

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b813597a265c702db717d1ed39341a2afcafc137

I will ask one more review when the result of the try is good.

(In reply to Tom Tung [:tt, :ttung] from comment #15)

https://treeherder.mozilla.org/#/jobs?repo=try&revision=b813597a265c702db717d1ed39341a2afcafc137

I will ask one more review when the result of the try is good.

I need to make the test security/manager/ssl/tests/unit/test_sss_sanitizeOnShutdown.js pass. A fix for that should be in another patch.

(In reply to Tom Tung [:tt, :ttung] from comment #16)

I need to make the test security/manager/ssl/tests/unit/test_sss_sanitizeOnShutdown.js pass. A fix for that should be in another patch.

Hmm, so this seems to be a complicated issue:

• sanitizeOnShutdown seems to be triggered by "profile-change-teardown"
• If the SWM hasn't been initialized yet, it would be lazily initialized in Services.clearData.deleteDataFromOriginAttributesPattern because of the change in D33758
• SWM::Init will add a shutdown blocker and the will be removed when it gets the topic "profile-change-teardown". (But I suspect, in this case, it won't because the topic has already fired)
• Because the added blocker is not removed, it blocks the process of shutting down.
• I need to check if this scenario occurs in other functions for clearData

If the sequence is not expected, SWM would just block the shutdown after the change I made in this bug.

Maybe a solution is not to init the SWM if it hasn't been initialized.

The test starts timed out after applying the changes in P1-P3. The main reason is that P1-P3 ensure SWM and the QuotaManger clear their storage in any condition in clear data service. However, since the SWM adds a shutdown blocker during the initialization and it's initialized during the profile-change-teardown because of the changes and the test scenario.

To fix that, ideally, SWM should differentiate if it's initialized before or during the profile-change-teardown and that requires a non-small change. Since we haven't got this signature in the real world and similar cases (SWM gets initialized during profile-change-teardown) have been taken care of, this patch only adds a workaround to avoid the issue.

Depends on D34325

https://treeherder.mozilla.org/#/jobs?repo=try&revision=78ec6ac0766b2583c88c518008cb9d0360fd036f

https://hg.mozilla.org/mozilla-central/rev/20dbddeeb3a6
https://hg.mozilla.org/mozilla-central/rev/51ddf8bf0847
https://hg.mozilla.org/mozilla-central/rev/ea125fda1920
https://hg.mozilla.org/mozilla-central/rev/bd7b2d89fa96