Closed
Bug 1309695
Opened 8 years ago
Closed 8 years ago
Firefox Developer - cache keeps getting cleared on shutdown
Categories
(Core :: Networking: Cache, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1311271
People
(Reporter: me, Assigned: mayhemer)
Details
(Whiteboard: [necko-active])
Attachments
(1 file)
(deleted),
application/x-zip-compressed
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:51.0) Gecko/20100101 Firefox/51.0
Build ID: 20161012004014
Steps to reproduce:
Clean profile and install
Do some browsing, build up a cache.
Close browser
Do some more browsing
Actual results:
The cache is cleared after a few seconds into the next session.
Tried with fresh install of 51.0a2 (2016-10-12) (64-bit) and clean profile.
The cache folder within the profile is emptied.
Expected results:
Cache should be retained until either manually cleared or items evicted.
Severity: normal → major
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Comment 1•8 years ago
|
||
Hey Mark,
I have tested this on Firefox 51.0a2 [aurora]. The cache folder within the profile is not emptied. Here is the screen capture: https://testing-1.tinytake.com/sf/MTA1NDE1Nl80MjY0NzQ3
If it is still reproducible to you, could you please provide the url for the pages you were browsing ? Any additional information is appreciated. Thanks
---
Version 51.0a2
Build ID 20161017004013
Update Channel aurora
User Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:51.0) Gecko/20100101 Firefox/51.0
Component: Untriaged → Networking: Cache
Product: Firefox → Core
Updated•8 years ago
|
Flags: needinfo?(me)
Assignee | ||
Comment 2•8 years ago
|
||
Reporter,
"The cache folder within the profile is emptied" - which folder is that exactly? Just to make sure that what you are looking at is really the folder of the HTTP cache location for the profile you use.
Is the folder completely empty when this bug happens?
Honestly, this sounds a bit strange. We didn't make any recent change (AFAIK) that would affect exactly this in Dev Edition. Tho, I will check the logs.
Severity: major → normal
Assignee | ||
Comment 3•8 years ago
|
||
Could you also provide a log from a session you observe this behavior at? Please read https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
Please change the log modules to:
MOZ_LOG_MODULES=cache2:5,sync,timestamp
Thanks. I suspect this could be related to some changes we made to http cache shutdown (bypass pending writes to avoid slow shutdown when on slower storage device). We may then find some (most) entries in a broken state and delete them.
If confirmed, this is either a WONTFIX or we may try to increase the shutdown delay time. Anyway, there are more plans on how we are going to use the http cache on slower storage devices.
Assignee | ||
Updated•8 years ago
|
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]
Hello All,
right, here is a youtube grab of it happening:
https://youtu.be/K1MdBfP4LqU
so, i've got about:config to use cache2, cache size is set to 1gb. the cache never grows to more than a few hundred items before it disappears. I've also notice everything vanish whilst in use.
the reason i noticed it was because my internet experience suddenly felt slow and I noticed frequently visited pages were having bits of graphics re-fetched.
the folder is the active cache folder for my profile - you can see it change. it does not matter which site you visit. it always happens.
Here is the HTTP log, as requested in post #3.
You can see the issue occurs at just after 19:19 utc, and if you scroll right to the bottom of the file, you see the deletions.
Flags: needinfo?(me)
Comment 7•8 years ago
|
||
The cache seems to be evicted due to this call:
CacheStorageService::DoomStorageEntries [context=O^userContextId=5,]
IIUC, CacheIndex doesn't understand userContextId attribute, so it behaves like no context was specified.
Assignee | ||
Comment 8•8 years ago
|
||
Thanks Mark and Michal. This is then duplicate of bug 1311271 which I'm going to fix soon.
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•