Open Bug 1748451 Opened 3 years ago Updated 6 months ago

Clearing cache storage still keeps several files

Categories

(Core :: Storage: Cache API, defect, P3)

defect

Tracking

()

REOPENED

People

(Reporter: saschanaz, Unassigned)

References

Details

(Whiteboard: dom-lws-bugdash-triage)

  1. Get a new profile
  2. Access mozilla.slack.com and sign in
  3. If the load completes, turn on DevTools, go Storage, and delete every cache tables (gantry-*)
  4. Open a new tab
  5. Close the Slack tab
  6. Close Nightly

Expected: No files?
Actual: 13 files with total 3.61 MB size remain in (profile)/storage/default/https+++app.slack.com/cache/morgue. cache.sqlite only lists https://app.slack.com/service-worker.js which is probably acceptable, but it's 61 KB, which is way smaller than the total cache file size.

Edit: The size may be different, I retried and this time it was 15 MB total size of remaining cache.

Severity: -- → S3
Priority: -- → P3
See Also: → 1745178
See Also: → 1784700

Slack gave up on service workers, so comment #0 is not reproducible anymore.

I tried https://wpt.live/service-workers/cache-storage/cache-add.https.any.serviceworker.html instead, which adds and deletes caches, thus doing similar thing compared to comment #0. And after the test there are 5 files and 17 folders in storage/default/https+++wpt.live/cache/morgue, even though devtools says there's no cache entry. Restarting browser did not trigger an extra cleanup.

Summary: Opening Slack and clearing Cache still keeps several files → Clearing cache storage still keeps several files

Cache storage has a chrome namespace which we use to store the serviceworker scripts. If there are any installed ServiceWorkers for the origin, they will still exist. They can also currently leak; bug 1964413 is the first step in addressing bug 1668743 by helping us not lose track of ServiceWorkers that never made it to active and we shutdown, leaking them. Bug 1665197 tracks GC-ing the leaked workers as a cleanup / backstop.

(In reply to Kagami Rosylight [:saschanaz] (they/them) from comment #1)

Restarting browser did not trigger an extra cleanup.

Cache API supports a concept of an "orphan" cache where there is still a live reference to the Cache in memory via the DOM which then requires all of the request/response pairs it contains to still be available for use. We clean this up when when the CacheManager for the origin is next initialized in the event of unclean shutdown. Does your STR here include ensuring that the Cache API is used after restarting? Alternately, closing the tab and ensuring any SW globals have been terminated should clean these up. (The SW does normally get a grace period, plus the Cache API may keep a worker alive slightly longer to drain its list of operations.)

Status: NEW → RESOLVED
Closed: 6 months ago
Flags: needinfo?(krosylight)
Resolution: --- → FIXED
Whiteboard: dom-lws-bugdash-triage

(whoops, reopening; I had changed course to NI and leave open but the reload of the page didn't fully reset the dupe state I was going with initially)

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

So...

  1. mozregression --launch 2025-06-01 --profile test-profile-1748451 --profile-persistence=reuse --arg="https://wpt.live/service-workers/cache-storage/cache-add.https.any.serviceworker.html"
  2. Wait until the test ends
  3. Check the cache storage is empty per the devtools
  4. Close the browser
  5. mozregression --launch 2025-06-01 --profile test-profile-1748451 --profile-persistence=reuse --arg="https://not.wpt.live/service-workers/cache-storage/cache-add.https.any.serviceworker.html" (Note the not.wpt.live)
  6. Check the cache storage is empty per the devtools
  7. Now check whether the directory test-profile-1748451/storage/default/ still has a subdirectory https+++wpt.live.

Expected: The directory should go
Actual: A bunch of files and mostly empty sub directories are there in https+++wpt.live/cache/morgue/.

The test uses cache_test that cleans up the cache:

  // Returns a promise that resolves to a newly created Cache object. The
  // returned Cache will be destroyed when |test| completes.
  function create_temporary_cache(test) {
    var uniquifier = String(++next_cache_index);
    var cache_name = self.location.pathname + '/' + uniquifier;

    test.add_cleanup(function() {
        self.caches.delete(cache_name);
      });

    return self.caches.delete(cache_name)
      .then(function() {
          return self.caches.open(cache_name);
        });
  }

  self.create_temporary_cache = create_temporary_cache;
Flags: needinfo?(krosylight)

Repeating the steps 1-4 keeps the list of subdirectories growing, while the length of file list stays at 5. Meaning all of the added subdirectories are empty.

You need to log in before you can comment on or make changes to this bug.