User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0

Steps to reproduce:

From History > Today panel item, right-clicked site and selected Forget About This Site > Forget

Actual results:

In addition to forgetting selected site's cache, cookies, etc., my entire disk cache was deleted.

Expected results:

Only forget cache, cookies, etc. for the selected site, while leaving disk cache otherwise intact.

Additionally, as reported by another user on Reddit, I've confirmed that clicking the padlock icon in the address bar to select "clear cookies and site data..." for a given site also deletes my disk cache. I'm not sure if another bug report would be necessary or if they're two parts of the same problem.

How do you know that the entire disk cache is deleted, rather than just the relevant site? Did you check about:cache? Also, can you reproduce the issue with a new Firefox profile?

(Not setting NI because reporter has NI disabled)

(In reply to Paul Zühlcke [:pbz] from comment #2)

How do you know that the entire disk cache is deleted, rather than just the relevant site? Did you check about:cache? Also, can you reproduce the issue with a new Firefox profile?

(Not setting NI because reporter has NI disabled)

I have my .../firefox/cache2/entries folder open when I do it, and can see it empty in real time.

I just tried it with a fresh profile. I loaded YouTube and scrolled the front page until the cache was over 30 MB, then went to example.com, and used Forget About This Site to forget example.com. My cache immediately dropped to under 1 MB, with a bunch of 0 byte 'empty document' files and a handful of files of 'type unknown' surviving.

Thanks! I'll try to reproduce this and look into the bug. Bug 1705030 added the clearing by base domain for cache. I'm curious whether this was broken to begin with or is a more recent regression.

Reporter, are you familiar with the mozregression tool? If you want to you can try to find the regression with that. Here is a quick intro: https://mozilla.github.io/mozregression/quickstart.html

I've never used it before, but I think I've got it figured out. I haven't found the offending version yet but it started after Nightly 2021-03-29. Still searching!

It looks like the earliest offending version is Nightly 2021-06-25 and Nightly 2021-06-24 was fine, but mozregression-gui crashed several times during this process and I don't think I'll be trying this again.

I can see cache entries of youtube getting pruned when running "Forget about this site" for example.com. My STR:

With a fresh profile:

1. visit youtube.com
2. open a second tab and visit example.com
3. in a third tab open about:cache?storage=disk and observe cache files for youtube (and subdomains)
4. Clear data for example.com via hamburger menu => history => right click "example.com" => Forget about this site

Expected:
Youtube should still have cache entries with data attached to them

Actual:
Most cache entries have a size of 0

Using mozregression I found this range:

13:38.16 INFO: First bad revision: e15c1956a0ebadaf0e4e869eb8c7e24667d63359
13:38.16 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=fd5088801f6d8fc24833c33704aadd128ed094a5&tochange=e15c1956a0ebadaf0e4e869eb8c7e24667d63359

Kershaw, could this be a regression of Bug 1733958? The forget about this site feature calls clearBaseDomain: https://searchfox.org/mozilla-central/rev/0d7e190891e62276cf934cc0b96b22e8e086ddb9/netwerk/cache2/nsICacheStorageService.idl#64
Do my STR make sense or could there be some other side effects leading to these cache entries being pruned?

Valentin, do you probably have an idea here?
I think the the cache deletion of youtube.com is not caused by Forget about this site, but I don't have enough knowledge about the real reason.

I can reproduce this bug.
I remember a conversation a while ago with some of the necko peers saying that when we purge the cache for one domain, we actually do it for the entire cache because it's easier that iterating through the cache 🙂
That said, I couldn't find which of the cache APIs does that. We do have a testing gap in the data sanitization tests in that we don't check the rest of the cache is still there after sanitizing one site.
I'll keep the needinfo for now. If someone can narrow down the problem for me I can attempt a fix.

Doesn't ClearBaseDomain (which is called by the feature) iterate over individual entries though?
https://searchfox.org/mozilla-central/rev/30ac44262374be08ccd4262ee36f0716152868d3/netwerk/cache2/CacheStorageService.cpp#744
Or does that result in clearing the entire cache somewhere down the line?

Set release status flags based on info from the regressing bug 1733958

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.

Set release status flags based on info from the regressing bug 1733958

Hannah, could you set a prirority and severity to this bug? Thanks

(In reply to Paul Zühlcke [:pbz] from comment #10)

Doesn't ClearBaseDomain (which is called by the feature) iterate over individual entries though?
https://searchfox.org/mozilla-central/rev/30ac44262374be08ccd4262ee36f0716152868d3/netwerk/cache2/CacheStorageService.cpp#744
Or does that result in clearing the entire cache somewhere down the line?

This is somewhere down the line in the cache implementation.
This has been a known issue for a number of years - it wasn't actually regressed by 1733958 though that may have some interaction here.
I'll just move this into Core::Networking since that's where the bug is.