Storage folders of containers removed with contextualIdentities.remove aren't deleted

ASSIGNED
Assigned to

Status

()

defect
P3
normal
ASSIGNED
11 months ago
3 days ago

People

(Reporter: emailmeat, Assigned: tt)

Tracking

67 Branch
Points:
---

Firefox Tracking Flags

(firefox61 affected, firefox62 affected, firefox63 affected)

Details

(Whiteboard: [domsecurity-backlog1])

Attachments

(6 attachments)

Reporter

Description

11 months ago
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0
Build ID: 20180704003137

Steps to reproduce:

- Install https://addons.mozilla.org/addon/temporary-containers/
- Set it to delete containers "After the last tab in it closes"
- Browse websites that make use of local storage, like https://www.facebook.com and https://www.folha.uol.com.br/
- Close those tabs


Actual results:

Firefox keeps storage folders for those containers in my profile folder, even though they've been removed with contextualIdentities.remove (https://github.com/stoically/temporary-containers/issues/127#issuecomment-385382460). Even after restarting Firefox, the folders are still kept.




Expected results:

Storage folders of removed containers should be completely wiped.

Comment 1

11 months ago
Hi, I managed to reproduce this issue using the latest version of Firefox Nightly 63.0a1 (2018-07-12)and the created folders are not deleted from the Profile folder after the user closes the last tab from temporary containers.
Status: UNCONFIRMED → NEW
Component: Untriaged → Add-ons Manager
Ever confirmed: true
OS: Unspecified → Windows 10
Product: Firefox → Toolkit
Hardware: Unspecified → x86

Comment 2

11 months ago
The webextensions API just calls ContextualIdentityService.remove().  That does appear to clear associated storage:
https://searchfox.org/mozilla-central/rev/46292b1212d2d61d7b5a7df184406774727085b8/toolkit/components/contextualidentity/ContextualIdentityService.jsm#298-299

Over to the containers maintainers to look at (or WONTFIX)
Component: Add-ons Manager → DOM: Security
Product: Toolkit → Core
Reporter

Updated

11 months ago
OS: Windows 10 → All
Hardware: x86 → All
This storage probably should be cleaned up. ni Baku because I know you are working on storage things at the moment.
Flags: needinfo?(amarchesini)
Priority: -- → P3
Whiteboard: [domsecurity-backlog1]
Reporter

Updated

9 months ago
Version: 61 Branch → 62 Branch
Reporter

Updated

8 months ago
Version: 62 Branch → 63 Branch
Reporter

Updated

6 months ago
Version: 63 Branch → 64 Branch
Reporter

Updated

5 months ago
Version: 64 Branch → 65 Branch
Reporter

Updated

3 months ago
Version: 65 Branch → 66 Branch

Comment 4

3 months ago

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
Reporter

Comment 5

3 months ago

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).

Reporter

Updated

26 days ago
Version: 66 Branch → 67 Branch

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?

Flags: needinfo?(amarchesini) → needinfo?(jvarga)

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.

Flags: needinfo?(jvarga) → needinfo?(shes050117)
Assignee

Comment 8

25 days ago

(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.

Assignee

Updated

25 days ago
Assignee: nobody → shes050117
Status: NEW → ASSIGNED
Component: DOM: Security → DOM: Quota Manager
Flags: needinfo?(shes050117)

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

Attachment #9069886 - Attachment description: Bug 1474608 - Notify category entry for clear-origin-attributes-data so that QuotaManagerService can be notified; → Bug 1474608 - P1 - Clear origin attributes directly for deleteDataFromOriginAttributesPattern if it's possible;
You need to log in before you can comment on or make changes to this bug.