Cache data not clearing on close but only can be removed with manual purge of history in v125.0.1
Categories
(Core :: Networking: Cache, defect, P2)
Tracking
()
People
(Reporter: mirawebdesign, Unassigned)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged])
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Steps to reproduce:
In v125.0.1 my settings include purging cache on close. Noticed that data was remaining in the cache. Turned off cache on close option. Restarted browser. Re-enabled cache on close, restarted, visited a site, and closed. Observed data was again retained in cache. Able to purge cache manually from history. Have two profiles, same behavior in each.
Actual results:
Cache retained data even though browser setting was enabled to purge cache on close. Cache retention is changing behavior on websites that indicate that tracking information is also being retained in the cache.
Expected results:
Cache data should have gone to 0. It remained at a high number.
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:125.0) Gecko/20100101 Firefox/125.0
Updated•2 years ago
|
I have been able to test this issue against the Washington Post website. The site's behavior changes if the cache is not completely purged. On close, it leaves a consistent 294kb in the cache. If that data remains present after a request to purge the cache on close, the Washington Post uses a different "subscribe now" message than if it has been cleared by manually using the settings menu. Unclear if the same data has behaviors on other websites, is set by the Washington Post or someone else (multisite collector?) or why it is not clearing on close.
Comment 2•2 years ago
|
||
The severity field is not set for this bug.
:decoder, could you have a look please?
For more information, please visit BugBot documentation.
Comment 3•2 years ago
|
||
This has nothing to do with sanitizers, moving back into triage.
Comment 4•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Networking: Cache' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Updated•2 years ago
|
Updated•2 years ago
|
I think we have a bug for this. Will dupe.
Description
•