Open Bug 1941111 Opened 2 months ago Updated 23 days ago

Cache data suddenly drops from disk

Categories

(Core :: Networking: Cache, defect, P2)

Product:
Core
Component:
Networking: Cache
Version:
Firefox 133
Type:
defect

Tracking

()

People

(Reporter: td44.ringo.apple, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged][necko-priority-next])

Attachments

(13 files)

Screenshot 2025-01-10 at 07-38-30 Network Cache Storage Information.png
70.89 KB, image/png
Details
Screenshot 2025-01-11 at 08-21-05 Network Cache Storage Information.png
67.16 KB, image/png
Details
Screenshot 2025-01-11 at 19-38-41 Network Cache Storage Information.png
71.05 KB, image/png
Details
Screenshot from 2025-01-14 22-12-05.png
180.32 KB, image/png
Details
Screenshot 2025-01-15 at 21-42-47 Network Cache Storage Information.png
54.23 KB, image/png
Details
Screenshot from 2025-01-15 21-43-02.png
179.05 KB, image/png
Details
firefox-log.txt-main.248991.moz_log.cut1.zip
5.15 MB, application/zip
Details
firefox-log.txt-main.2030.moz_log.cut1.zip
4.85 MB, application/zip
Details
console-export-2025-1-21_20-59-17.txt
57.80 KB, text/plain
Details
Screenshot 2025-01-21 at 21-47-02 トラブルシューティング情報.png
488.37 KB, image/png
Details
prefs.js
25.01 KB, application/x-javascript
Details
console-export-2025-1-22_21-19-16.txt
30.80 KB, text/plain
Details
add-ons.txt
1.56 KB, text/plain
Details

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

Steps to reproduce:

I use cache disk with browser.cache.disk.smart_size.enabled = false and browser.cache.disk.capacity = 2,000,000 from before.

In addition to this, change default value of network.buffer.cache.count or network.buffer.cache.size count, cause drops cache data from disk at a certain timing.

Actual results:

"Storage in use: " grows up to a certain level, but suddenly drops cache data to bellow 30MB.

Expected results:

browser.cache.disk.smart_size.enabled = false and network.buffer.cache.count or network.buffer.cache.size is not default value, keep cache data to "Maximum storage size: ".

Sorry, I didn't know how to reopen it so I made a new entry.
bug 1938792

I tried Firefox ESR 128.6.0.

The behaivier of cache data control seems different clearly.

Below is a comparison of cache usage over time.
(I added three screenshot files, when I use Firefox ESR)

Firefox ESR 128.6.0
2025-01-10 07:38:30 1606866 KiB
2025-01-11 08:21:05 1999992 KiB
2025-01-11 19:38:41 1999760 KiB

Firefox 133.0.3
2024-12-25 21:02:17 978059 KiB
2024-12-25 22:05:46 6886 KiB

Looking at these results, it seems that the cache control logic has changed since Firefox 129 or later. Is this correct?

Thanks for the report.
It is impossible to tell why the cache size goes down during your session without more information.

  • Does the cache size drop if you leave the browser unused? Or does it only happen while browsing?
  • Do you ever clear history for a site?
  • Could you capture some HTTP logs while reproducing the bug? I recommend using this about:logging?modules=timestamp,sync,cache2:5 to capture the log.

Thanks!

Flags: needinfo?(td44.ringo.apple)

Thank you for your response.

Does the cache size drop if you leave the browser unused? Or does it only happen while browsing?

It happenes at running the Firefox.

Do you ever clear history for a site?

Yes, I set to "clear history at stopping Firefox = on" at settings.

Could you capture some HTTP logs while reproducing the bug? I recommend using this about:logging?modules=timestamp,sync,cache2:5 to capture the log.

I could reproduced it, but log file seems empty or not catched. Please see attached file of a screenshot.

firefox-log.txt-main.226445.moz_log
Log record has captured, but It seems that the log for the relevant time period is not included.
Because it happened at 21:54, and time stamp of a log file updated is 20:34. (both are local time)

firefox-log.txt-main.235833.moz_log
Log file seems empty. it happened at 22:03. (local time)

Flags: needinfo?(td44.ringo.apple)

Log file names and time stamps.

I could reproduced it, and captured the log file.

I attached three files.
log file: firefox-log.txt-main.248991.moz_log (zipped)
screenshot of file list:Screenshot from 2025-01-15 21-43-02.png
screenshot of about:cache:Screenshot from 2025-01-15 21-42-47 Network Cache Storage Information.png

It happened aroud at 21:42. (local time, UTC +9)

It seems that the "storage in use" has decreased from 800MB to 300MB.

My Firefox version is 134.0 now.

screenshot of about:cache

screenshot of file list

log file (cutted by last 500,000 lines)
all lines is 3,589,698.

Sorry, log file was too large to attach.

So, cutted last 500,000 lines, and zipped. All lines is 3,589,698.

If it seems that it is missing, please request the necessary part.

2025-01-15 12:41:55.231321 UTC - [Parent 248991: Main Thread]: D/cache2 CacheFileIOManager::EvictByContext() [loadContextInfo=0]
2025-01-15 12:41:55.231356 UTC - [Parent 248991: Cache2 I/O]: D/cache2 CacheFileIOManager::EvictByContextInternal() [loadContextInfo=0, pinned=0]

Based on the diagram, something is calling clearing the cache.

Do you have any extensions?

Yes, I set to "clear history at stopping Firefox = on" at settings.

If you disable this option, do things work as usual?
Could you also try setting privacy.purge_trackers.enabled to false in about:config and check if that fixes it?

Flags: needinfo?(td44.ringo.apple)

I tried "clear history at stopping Firefox = off", and it works well for workaroud.

And privacy.purge_trackers.enabled is still true.

This is Firefox 134.0.1 on Windows.

Flags: needinfo?(td44.ringo.apple)

(In reply to Grey Orion from comment #14)

I tried "clear history at stopping Firefox = off", and it works well for workaroud.

It is slightly surprising that Clear history when Firefox closes would cause the cache to get purged when Firefox is still running.
Emma, do you have any idea how this could happen? Could you suggest some way to diagnose what is triggering this?

Flags: needinfo?(emz)

Could set browser.sanitizer.loglevel e.g. to Debug and see if the log messages show something clearing the cache. Does the cache get cleared without any kind of restart?

In that case it's additionally worth checking if it's related to tracker purging, or Bounce Tracking Protection, which also does hourly purging:

Tracker purging can be disabled via privacy.purge_trackers.enabled as Valentin mentioned.
Bounce Tracking Protection can be disabled by setting privacy.bounceTrackingProtection.mode to 3. If it's already on a value != 1 though it shouldn't purge to begin with.

Flags: needinfo?(emz)

I could reproduced with these conditions.

  • Clear history when Firefox closes = true
  • browser.sanitizer.loglevel = Debug
  • about:logging?modules=timestamp,sync,cache2:5
  • privacy.purge_trackers.enabled = true
  • privacy.bounceTrackingProtection.mode = 1

I will attach the log file later.

These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = false
  • privacy.bounceTrackingProtection.mode = 1

I will try privacy.bounceTrackingProtection.mode = 3 next.

log file that cutted last 500,000 lines.

It tooked these conditions.

  • Clear history when Firefox closes = true
  • browser.sanitizer.loglevel = Debug
  • about:logging?modules=timestamp,sync,cache2:5
  • privacy.purge_trackers.enabled = true
  • privacy.bounceTrackingProtection.mode = 1

These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = true
  • privacy.bounceTrackingProtection.mode = 3

I will try privacy.purge_trackers.enabled = false and privacy.bounceTrackingProtection.mode = 3 next.

These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = false
  • privacy.bounceTrackingProtection.mode = 3

Looking at this result, it seems that only Clear history when Firefox closes = true is affected.

(In reply to Grey Orion from comment #21)

These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = false
  • privacy.bounceTrackingProtection.mode = 3

Looking at this result, it seems that only Clear history when Firefox closes = true is affected.

Sorry, this result is wrong conditions. I will try once more.

(In reply to Grey Orion from comment #22)

(In reply to Grey Orion from comment #21)

These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = false
  • privacy.bounceTrackingProtection.mode = 3

Looking at this result, it seems that only Clear history when Firefox closes = true is affected.

Sorry, this result is wrong conditions. I will try once more.

Also, These conditions also reproduced. No log file saved.

  • Clear history when Firefox closes = true
  • privacy.purge_trackers.enabled = false
  • privacy.bounceTrackingProtection.mode = 3

Looking at this result, it seems that only Clear history when Firefox closes = true is affected.

Thanks for the investigation! I'm glad we could rule out the other features. Let's see if anything interesting is logged from the Sanitizer.

If you set browser.sanitizer.loglevel to All you should be able to see Sanitizer log messages in the browser console. The Sanitizer should log messages with the prefix "Sanitizer: " to the browser console.

The Sanitizer shouldn't make any cache clearing calls during runtime - with one exception. If clearing on shutdown failed it may resume clearing on startup. You would see that in the log. It shouldn't happen in the middle of your session though, only after startup.

If you don't modify the cache prefs (browser.cache.*) does the issue still reproduce?

Flags: needinfo?(td44.ringo.apple)

log file of a browser.console

It reproduced but Sanitize not appeared.

Flags: needinfo?(td44.ringo.apple)

I tried with these conditions, and could reproduced. but browser console not appeared "Sanitizer: ".

  • Clear history when Firefox closes = true
  • browser.cache.* = default values

I think around line 639 (timestamp is 20:47:19.713) is it happened.

Thanks!

Hmm, that's odd. Can we make sure the logger is working? At least on startup you should see this line: https://searchfox.org/mozilla-central/rev/345ec3c55ddda5f0ce37168f0644dcdcc4834409/browser/modules/Sanitizer.sys.mjs#174 in the browser console.
Though I'd also expect to see some logging when the Sanitizer triggers data clearing (which would cause the cache to be cleared).

  1. Can you reproduce the issue with a fresh Firefox profile? I wonder if you set some other pref that's causing these issues.
  2. You mention Clear history when Firefox closes = true, which pref or setting in about:preferences is that exactly?
Flags: needinfo?(td44.ringo.apple)

Sorry, I had mistaken. I need restart Firefox once.
Now startup message has appeared. I will try reproduce, wait a while.

21:35:22.763 Sanitizer: Pending sanitizations: Array [] Sanitizer.sys.mjs:35:14

I've already tried refreshing the profile and it didn't resolved.

I attached a screenshot of about:support. Please let me know if you notice anything unusual.

Flags: needinfo?(td44.ringo.apple)

screenshot of about:support

section "Important Modified Preferences"

(In reply to Grey Orion from comment #29)

Created attachment 9460681 [details]
Screenshot 2025-01-21 at 21-47-02 トラブルシューティング情報.png

screenshot of about:support

section "Important Modified Preferences"

Thank you. Could you attach the pref list as a text file? There should be a copy button at the top. Feel free to strip out stuff that you don't want to share here.
I see a pending sanitization from one of the prefs. Could be related to this bug.

Flags: needinfo?(td44.ringo.apple)
Attached file prefs.js —

my prefs.js

Flags: needinfo?(td44.ringo.apple)

(In reply to Emma Zühlcke [:emz] from comment #30)

Thank you. Could you attach the pref list as a text file? There should be a copy button at the top. Feel free to strip out stuff that you don't want to share here.
I see a pending sanitization from one of the prefs. Could be related to this bug.

I attached my prefs.js.

browser console

It reproduced, but "Sanitizer: " is disappered.

I could reproduced. but browser console not appeared "Sanitizer: ".

I feel it happend at after one hours about startup of Firefox.

Thanks for the pref list and the logs. Clear on shutdown isn't even enabled for caches so it's very unlikely that this is triggered by Sanitizer directly. Further we don't see any log entries from it. From the rest of the prefs nothing stands out particularly.

Do you have any extensions installed that may call into the API to clear site data? I see that Valentin asked about it earlier but I don't see a reply.

Flags: needinfo?(td44.ringo.apple)

We can use the profiler to find out who calls the sanitizer.

  1. Go to about:logging?modules=timestamp,sync,nsHttp:5,cache2:5
  2. Make sure Logging to the Firefox Profiler and Enable stack traces for log messages are selected.
  3. Click Start Logging
  4. << Reproduce bug >> As far as I understand this happens after about an hour. Leave the browser open, with only one tab open to about:blank or example.com. You're using Linux, so you can use watch -n 60 du -sh /path/to/cache_folder to monitor the size of the cache.
  5. Once you see it drop, go to about:logging and click stop. Then click Upload local profile and either upload and send us the link, or download it and send it via dropbox/google drive. Make sure all the boxes are checked, so no info gets stripped. If you have any private info in the profile send it to necko@mozilla.com

Hopefully we can figure out from the stack traces where the call is coming from.

Attached file add-ons.txt —
Flags: needinfo?(td44.ringo.apple)

(In reply to Emma Zühlcke [:emz] from comment #35)

Do you have any extensions installed that may call into the API to clear site data? I see that Valentin asked about it earlier but I don't see a reply.

I attached my extensions. (add-ons.txt)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #36)

We can use the profiler to find out who calls the sanitizer.

  1. Go to about:logging?modules=timestamp,sync,nsHttp:5,cache2:5
  2. Make sure Logging to the Firefox Profiler and Enable stack traces for log messages are selected.
  3. Click Start Logging
  4. << Reproduce bug >> As far as I understand this happens after about an hour. Leave the browser open, with only one tab open to about:blank or example.com. You're using Linux, so you can use watch -n 60 du -sh /path/to/cache_folder to monitor the size of the cache.
  5. Once you see it drop, go to about:logging and click stop. Then click Upload local profile and either upload and send us the link, or download it and send it via dropbox/google drive. Make sure all the boxes are checked, so no info gets stripped. If you have any private info in the profile send it to necko@mozilla.com

Hopefully we can figure out from the stack traces where the call is coming from.

I could reproduced it, and taken Firefox Profiler data with stack traces.

The file name is Firefox 2025-01-24 08.37 profile.json.gz, and size is 93.5MB.

I will send this file by mail later.

This time it occurs about 2 hours after starting Firefox.

Thank you for the profile. It managed to capture the stack trace:

mozilla::LogModuleManager::ActuallyLog(char const*, mozilla::LogLevel, mozilla::TimeStamp const*, char const*, char const*, unsigned long)xpcom/base/Logging.cpp
mozilla::LogModuleManager::Print(char const*, mozilla::LogLevel, mozilla::TimeStamp const*, char const*, char const*, __va_list_tag*)xpcom/base/Logging.cpp
mozilla::LogModuleManager::Print(char const*, mozilla::LogLevel, char const*, __va_list_tag*)xpcom/base/Logging.cpp
mozilla::LogModule::Printv(mozilla::LogLevel, char const*, __va_list_tag*) constxpcom/base/Logging.cpp
mozilla::detail::log_print(mozilla::LogModule const*, mozilla::LogLevel, char const*, ...)xpcom/base/Logging.cpp
mozilla::net::CacheFileIOManager::EvictByContext(nsILoadContextInfo*, bool, nsTSubstring<char16_t> const&, nsTSubstring<char16_t> const&)netwerk/cache2/CacheFileIOManager.cpp
mozilla::net::CacheStorageService::ClearBaseDomain(nsTSubstring<char16_t> const&)netwerk/cache2/CacheStorageService.cpp
NS_InvokeByIndexlibxul.so
CallMethodHelper::Invoke()js/xpconnect/src/XPCWrappedNative.cpp
CallMethodHelper::Call()js/xpconnect/src/XPCWrappedNative.cpp
XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)js/xpconnect/src/XPCWrappedNative.cpp
nsICacheStorageService.clearBaseDomain
XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*)js/xpconnect/src/XPCWrappedNativeJSOps.cpp
CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&)js/src/vm/Interpreter.cpp
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)js/src/vm/Interpreter.cpp
InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)js/src/vm/Interpreter.cpp
js::CallFromStack(JSContext*, JS::CallArgs const&, js::CallReason)js/src/vm/Interpreter.cpp
js::Interpret(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
MaybeEnterInterpreterTrampoline(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::RunScript(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)js/src/vm/Interpreter.cpp
InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)js/src/vm/Interpreter.cpp
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)js/src/vm/Interpreter.cpp
deleteBySiteresource://gre/modules/ClearDataService.sys.mjs:498:21
deleteDataFromSite/<resource://gre/modules/ClearDataService.sys.mjs:2416:52
_deleteInternal/promises</<resource://gre/modules/ClearDataService.sys.mjs:2574:24
js::RunScript
js::jit::InvokeFunction(JSContext*, JS::Handle<JSObject*>, bool, bool, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>)js/src/jit/VMFunctions.cpp
js::jit::InvokeFromInterpreterStub(JSContext*, js::jit::InterpreterStubExitFrameLayout*)js/src/jit/VMFunctions.cpp
0x356420914d75
0x356420e725ec
mapself-hosted:175:18
js::Interpret(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
MaybeEnterInterpreterTrampoline(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::RunScript(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)js/src/vm/Interpreter.cpp
InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)js/src/vm/Interpreter.cpp
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)js/src/vm/Interpreter.cpp
_deleteInternal/promises<resource://gre/modules/ClearDataService.sys.mjs:2572:63
js::RunScript
js::jit::InvokeFunction(JSContext*, JS::Handle<JSObject*>, bool, bool, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>)js/src/jit/VMFunctions.cpp
js::jit::InvokeFromInterpreterStub(JSContext*, js::jit::InterpreterStubExitFrameLayout*)js/src/jit/VMFunctions.cpp
0x356420914d75
mapself-hosted:175:18
js::Interpret(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
MaybeEnterInterpreterTrampoline(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::RunScript(JSContext*, js::RunState&)js/src/vm/Interpreter.cpp
js::InternalCallOrConstruct(JSContext*, JS::CallArgs const&, js::MaybeConstruct, js::CallReason)js/src/vm/Interpreter.cpp
InternalCall(JSContext*, js::AnyInvokeArgs const&, js::CallReason)js/src/vm/Interpreter.cpp
js::Call(JSContext*, JS::Handle<JS::Value>, JS::Handle<JS::Value>, js::AnyInvokeArgs const&, JS::MutableHandle<JS::Value>, js::CallReason)js/src/vm/Interpreter.cpp
_deleteInternalresource://gre/modules/ClearDataService.sys.mjs:2570:18
deleteDataFromSiteresource://gre/modules/ClearDataService.sys.mjs:2394:21
deleteDataFromSiteAndOriginAttributesPatternStringresource://gre/modules/ClearDataService.sys.mjs:2425:53
js::RunScript
JS_CallFunctionValue(JSContext*, JS::Handle<JSObject*>, JS::Handle<JS::Value>, JS::HandleValueArray const&, JS::MutableHandle<JS::Value>)js/src/vm/CallAndConstruct.cpp
nsXPCWrappedJS::CallMethod(unsigned short, nsXPTMethodInfo const*, nsXPTCMiniVariant*)js/xpconnect/src/XPCWrappedJSClass.cpp
XPCWrappedJS method call
PrepareAndDispatchxpcom/reflect/xptcall/md/unix/xptcstubs_x86_64_linux.cpp
SharedStublibxul.so
mozilla::BounceTrackingProtection::PurgeStateForHostAndOriginAttributes(nsTSubstring<char> const&, long, mozilla::OriginAttributes const&, mozilla::MozPromise<nsTString<char>, unsigned int, true>**)toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp
mozilla::BounceTrackingProtection::PurgeBounceTrackersForStateGlobal(mozilla::BounceTrackingStateGlobal*, mozilla::BounceTrackingAllowList&, nsTArray<RefPtr<mozilla::MozPromise<nsTString<char>, unsigned int, true> > >&)toolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp
mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0::operator()(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&) consttoolkit/components/antitracking/bouncetrackingprotection/BounceTrackingProtection.cpp
mozilla::MozPromise<bool, nsresult, false>::InvokeMethod<mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0, void (mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0::*)(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&) const, mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&>(mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0*, void (mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0::*)(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&) const, mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&)xpcom/threads/MozPromise.h
mozilla::MozPromise<bool, nsresult, false>::InvokeCallbackMethod<false, mozilla::MozPromise<bool, nsresult, false>, mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0, void (mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0::*)(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&) const, mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&>(mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0*, void (mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0::*)(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&) const, mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue const&)xpcom/threads/MozPromise.h
mozilla::MozPromise<bool, nsresult, false>::ThenValue<mozilla::BounceTrackingProtection::PurgeBounceTrackers()::$_0>::DoResolveOrRejectInternal(mozilla::MozPromise<bool, nsresult, false>::ResolveOrRejectValue&)xpcom/threads/MozPromise.h
mozilla::MozPromise<RefPtr<_GDBusProxy>, mozilla::UniquePtr<_GError, mozilla::GFreeDeleter>, true>::ThenValueBase::DoResolveOrReject(mozilla::MozPromise<RefPtr<_GDBusProxy>, mozilla::UniquePtr<_GError, mozilla::GFreeDeleter>, true>::ResolveOrRejectValue&)xpcom/threads/MozPromise.h
...

The call seems to be coming from the BounceTrackingProtection.
As far as I can tell, the pattern used to purge the cache here is intentionally pretty broad, and clears across partitions.

I also noticed NetworkCacheCleaner.deleteBySite has a TODO to include the oapattern which I'm not sure is related to the current bug.

@Emma, can you check if the callsites above appear to be correct?

Flags: needinfo?(emz)

I also recall there was an issue where some calls to clear the cache for a site would sometimes clear the entire disk cache. I think I'll need to write some tests for that.

Good find, thank you!

BounceTrackingProtection will clear the cache of all sites which have been detected as bounce trackers roughly every hour.

The clear call targets a specific schemeless site (base domain) and an OriginAttributes pattern. Since the cleaner has not been updated yet, we will clear all the cache for the tracking site. Since its site scoped the clear is still quite narrow and I would not expect larger amounts of cache to be cleared.

I suspect that there may be a bug in the clear by basedomain method of the cache that drops more cache than expected.

I’ll state the obvious: Over-clearing the cache across sites is undesired and may lead to performance degradation.

Flags: needinfo?(emz)
Blocks: btp
Severity: -- → S3
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-next]

Bug 1863250 may be related to this bug.

Good find, thank you! This does look like it may be related.

See Also: → 1863250
Status: UNCONFIRMED → NEW
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: