User Agent: Mozilla/5.0 (Windows NT 6.1; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release) Build ID: 20130618035212 Steps to reproduce: 1) create folder Firefox on drive X: 2) set browser.cache.disk.parent_directory to X:\Firefox 3) restart ---- This setup has worked for me for at least a year and nothing has ever changed about it. Just now I noticed the folder wasn't being filled anymore (it's a RAM disk created by a Batch file, so it's empty every time except for the predefined Firefox folder). There is no folder called Cache that belongs to Firefox anywhere. Memory caching seems to work, but Disk caching isn't happening (checked with CacheViewer Continued). Permissions are all fine and Chrome can write its cache files there when told to. Files are not hidden or System-hidden. Windows 7 SP1 x86, Firefox 22.0 Actual results: Disk cache does not exist at all Expected results: Cache folder in X:\Firefox with cache files
Could you determine in which version this stopped working by running the old releases at ftp://ftp.mozilla.org/pub/firefox/releases/ with new profiles with the pref set accordingly?
(In reply to Josh Matthews [:jdm] from comment #1) > Could you determine in which version this stopped working by running the old > releases at ftp://ftp.mozilla.org/pub/firefox/releases/ with new profiles > with the pref set accordingly? There must be something else going on here - I've gone all the way back to 3.6 and it still wasn't caching anything. I used a fresh profile with the parent_directory pref set, so it's not like there's another pref that's disabling it. Does the disk cache have any technical requirements or anything that could prevent its usage? Minimum available space, fixed/removable device requirement, etc? I thought maybe I wasn't browsing enough to have anything cached (about:home + random search word -> google result page -> techsupportalert.com), but since the Cache folder is not even being made at all, that seems unlikely. In the past the folder was always created automatically and filled with blank files at startup, whether anything was being cached or not.
(In reply to Josh Matthews [:jdm] from comment #1) > Could you determine in which version this stopped working by running the old > releases at ftp://ftp.mozilla.org/pub/firefox/releases/ with new profiles > with the pref set accordingly? A second try with another fresh profile did make it work... I don't get it. I'll continue testing with different releases and profiles.
Problem solved: it's a user pref that's not behaving correctly. Clear History when Firefox closes -> Cache: true It doesn't just clear the cache on exit, it simply prevents it from even being created.
Yes, the cache service code uses that privacy.sanitize.sanitizeOnShutdown pref to decide whether to enable the disk cache or not. I think the idea is that clearing the disk cache at shutdown can lead to unacceptable pauses, whereas only using the memory cache requires no special behaviour changes.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INVALID
That's just not right, IMHO... If a user asks to clear the cache at exit, the user should know that it might take a second and he'll expect Firefox to keep using the disk cache while browsing. Clear disk cache at exit =/= disable disk cache and is not what a user expects FF to do when setting that pref. Mis-applying preferences in a way that screws over advanced users for the sake of appearance towards people who don't know/care what they're doing is not the way to go, Mozilla.
"take a second" might be considered acceptable. Unbounded periods of time when the Firefox window goes unresponsive after the user has explicitly said they want to close the window is not a great situation, however. Sometimes these technical tradeoffs have to be made to protect people who aren't advanced users.
(In reply to Josh Matthews [:jdm] from comment #7) > "take a second" might be considered acceptable. Unbounded periods of time > when the Firefox window goes unresponsive after the user has explicitly said > they want to close the window is not a great situation, however. Sometimes > these technical tradeoffs have to be made to protect people who aren't > advanced users. If a user goes around setting preferences like "clear disk cache on exit", he should know what the technical consequences are. If he doesn't know what he's doing and performance goes down in a way he's too blind to understand, that's his own fault. This was done to protect people who aren't advanced users, but the result is that people who ARE advanced users are lied to by the configuration settings. A RAM cache is not equivalent to a disk cache and sneakily swapping one for the other when merely told to empty one at a given time is not right. Besides, why not just close the window and keep the process running without one until the exit tasks are done?
We try to only expose UI preferences for modes of operation that are fully supported for all users with reasonable expectations of performance, security, etc. With regards to closing the window and leaving the process running, then we run the risk of triggering the dreaded "Firefox is running but not responding" dialog if the user tries to reopen the app. As I said, there are tradeoffs, and this one is unlikely to change until we have a disk cache that can be cleared in a less intrusive fashion.
(In reply to Josh Matthews [:jdm] from comment #9) > With regards to closing the window and leaving the process > running, then we run the risk of triggering the dreaded "Firefox is running > but not responding" dialog if the user tries to reopen the app. I still fail to see the problem with that. Setting FF to clear the cache on exit means configuring FF to perform a task while or immediately after closing the main window. Performing any task invariably requires time. Performing a task right after closing a window requires the program to run in the background for a certain time. Anyone who sets such options ought to have the brains to realize that. Setting such an option and then complaining that Firefox keeps running after closing the window is paradoxal and dumb, because that is exactly what the users says he wants FF to do. Whether it'll be changed or not, the logic behind the implementation is based on users being brainless.
You need to log in before you can comment on or make changes to this bug.