Using "Forget About This Site" in History panel deletes disk cache
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
People
(Reporter: southwindcg, Unassigned)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
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.
Reporter | ||
Comment 1•2 years ago
|
||
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.
![]() |
||
Updated•2 years ago
|
Updated•2 years ago
|
Comment 2•2 years ago
|
||
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)
Reporter | ||
Comment 3•2 years ago
|
||
(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.
Comment 4•2 years ago
|
||
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
Reporter | ||
Comment 5•2 years ago
|
||
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!
Reporter | ||
Comment 6•2 years ago
|
||
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.
Comment 7•2 years ago
|
||
I can see cache entries of youtube getting pruned when running "Forget about this site" for example.com. My STR:
With a fresh profile:
- visit youtube.com
- open a second tab and visit example.com
- in a third tab open
about:cache?storage=disk
and observe cache files for youtube (and subdomains) - 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?
Comment 8•2 years ago
|
||
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.
Comment 10•2 years ago
|
||
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?
Comment 11•2 years ago
|
||
Set release status flags based on info from the regressing bug 1733958
Updated•2 years ago
|
Comment 12•2 years ago
|
||
The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 13•2 years ago
|
||
Set release status flags based on info from the regressing bug 1733958
Comment 14•2 years ago
|
||
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.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Description
•