Clear storage is returning the incorrect value
Reported by
matt.t.g...@gmail.com,
Dec 15 2017
|
||||||||
Issue description
UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36
Steps to reproduce the problem:
1. Go to a page that uses the cache
2. Notice size in clear storage tab
3. Refresh the page and notice the storage quota goes up
4. Repeat 3 several times (maybe 10 - 20)
What is the expected behavior?
The cache size to reflect the amount cached.
What went wrong?
The cache size seems to double with every refresh even though the cache doesn't get used
Did this work before? N/A
Chrome version: 62.0.3202.94 Channel: n/a
OS Version:
Flash Version:
Running the following scripts shows a value more close to the amount used:
const payload = {
total: 0,
};
const cacheNames = await caches.keys();
payload.cacheInfo = await Promise.all(cacheNames.map(async (cacheName) => {
const requests = {}
const cache = await caches.open(cacheName);
const requestKeys = await cache.keys();
await Promise.all(
requestKeys.map(async (requestKey) => {
const origin = new URL(requestKey.url, location).origin;
if (!requests[origin]) {
requests[origin] = {
count: 0,
size: 0,
};
}
const response = await cache.match(requestKey);
const blob = await response.blob();
requests[origin].count++;
requests[origin].size += blob.size;
payload.total += blob.size;
})
);
return {
cacheName,
cachedRequestsCount: requestKeys.length,
cachedRequests: requests,
};
}));
console.log(JSON.stringify(payload, null, 2));
,
Dec 15 2017
Reproduced on M63 using https://www.chromestatus.com/features, does not repro on ToT. Marking as RBS in case this is a real leak.
,
Dec 15 2017
,
Dec 15 2017
,
Dec 15 2017
,
Dec 15 2017
Rechecked this issue on Ubuntu 14.04 using chrome stable build 63.0.3239.108 and reported version 62.0.3202.94 using the URL provided in comment# 2. Unable to reproduce this. Storage quota remains the same for every refresh of the page. Attached a screen recording for the same. Kindly help if we have missed out any thing. Thanks.!
,
Dec 15 2017
No repro for me in 63 with https://www.chromestatus.com/features or https://jakearchibald.github.io/trained-to-thrill/ Passing off to cmumford@ - after discussion, we tentatively think this is what the mitigation in https://chromium-review.googlesource.com/c/chromium/src/+/755844 addresses. That's in 64 but not in 63. Summary: doomed caches get cleaned up when all handles are dropped; when refreshing a page there could be a race between when devtools queries usage and the handles from the previous page get dropped. The race explains why we can't repro consistently. The mitigation cmumford@ added in the change above makes doomed caches get flushed when queried by devtools so the reporting there is deterministic, which explains why pfeldman@ doesn't see it in ToT. But... we're not 100% confident on this; cmumford@ is going to follow up with pfeldman@ to make sure we're right. Dropping RBS for now as this would not be an actual leak, pending further data.
,
Dec 15 2017
Refreshing the page with DevTools open results in unbounded CacheStorage usage growth. Closing devtools and reopening does not help, GC does not help. However, not having DevTools open while reloading the page does not leak and does not result in the usage growth. DevTools inspects cachestorage over the same handles JS wrappers use, so you can consider DevTools to be a client retaining the caches, which would explain difference in behavior. All fixed in M64, not a huge issue in M63. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by matt.t.g...@gmail.com
, Dec 15 2017