+++ This bug was initially created as a clone of Bug #1233744 +++ The problem still does exist, but Cache handling has changed, so I doubt that it will be useful fo continue with Bug 1233744. User hbx found mysterious cache behavior at <https://seamonkeyde.wordpress.com/2016/09/24/nun-gibts-auch-seamonkey-2-49-trunk-builds-fuer-windows/#comment-347> Steps how to reproduce NOT reproducible REPRODUCIBLE with unofficial en-US SeaMonkey 2.49a1 (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20160930004545 (Default Classic Theme) on German WIN7 64bit: 0. Launch Browser → Menu ˋEdit → Preferences → Privacy and security → Private data - Check "Always Clear, Ask me, cache (all others unchecked) → Quit SeaMonkey → relaunch SM Browserˊ 1. After at least ¼ hr. using SM browser with at least 50 TABs having been opened and several of them closed again: menu 'File → Quit' (and confirm deletion of Cache) 2. Wait until SM is no longer visible in Task manager 3. Check <C:\Users\user\AppData\Local\Mozilla\SeaMonkey\Profiles\<yourprofile>\: rightclick on "\cache2\entries\"-folder → Properties » Every time I tested there were lots of files with several MB contents in the folder, in "entries" I saw lots of files with names like "FFF60ACA91627B86157D69660524225881D58AD7" Additionally there is a folder "cache2\doomed\" which will contain lots of files (they disappear after reelaunch of SM) Bug: cache folders should be empty a) This one might affect security

Still REPRODUCIBLE with official en-US SeaMonkey 2.49a1 (NT 6.1; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0 Build 20161005004944 (Default Classic Theme) on German WIN7 64bit NEW due to <https://unofficialseamonkeynews.wordpress.com/2016/08/04/my-unconfirmed-bug-reports/>

So, we are talking cache v2 here (switched in bug 1241622) whereas bug 1233744 was filed for the old cache? Please check with Firefox trunk, and if reproducible, move to the respective Core component.

Firefox 49.0.1 / W7 Pro seems to be affected too. Firefox is set to "always use private browsing mode". Content of C:\Users\$User\AppData\Local\Mozilla\Firefox\Profiles\$.default\cache2\entries is not deleted on shutdown. There are entries like "FBBC21E8866CD22196B9029664DA8E1D8D727F5B" (no extension) when i open them in notepad++ i can read -for example- the main menu of my ip-cam. If the history is cleared manually those files are still there but have no content.

(In reply to hallobox from comment #3) > Firefox 49.0.1 / W7 Pro seems to be affected too. Firefox is set to "always > use private browsing mode". > Content of > C:\Users\$User\AppData\Local\Mozilla\Firefox\Profiles\$. > default\cache2\entries is not deleted on shutdown. There are entries like > "FBBC21E8866CD22196B9029664DA8E1D8D727F5B" (no extension) when i open them > in notepad++ i can read -for example- the main menu of my ip-cam. > If the history is cleared manually those files are still there but have no > content. Those entries are probably leftover from sessions before you set the preference. When always PB is on, we don't store to disk at all. Please test with a new profile you switch to "never remember history" immediately.

(In reply to Honza Bambas (:mayhemer) from comment #4) We do not talk about "Private Browsing" here The original report is concerning the problem that hints in UI-dialogs concerning selected privacy preferences to "Clear Cache", what does not happen, at least not correctly. That is something completely different to "Do not write private data on HDD during PB". Without doubt the SeaMonkey bug does exist. And following <https://support.mozilla.org/en-US/kb/how-clear-firefox-cache#w_automatically-clear-the-cache> to select "Clear Cache when Quit" for FF also does not work for FF Nightly 52.0a1 (2016-09-26) (32-bit) @hallobox Can you please check whether your observations in PB match with Honza Bambas' explications? If your investigation shows that there is a Private Browsing cache deletion problem please submit a separate Bug!.

Clearing cache on shutdown works correctly in Firefox. The reason why it doesn't work in Seamonkey is that it calls nsICacheStorageService::clear() instead of setting "privacy.clearOnShutdown.cache" preference to true. nsICacheStorageService::clear() starts evicting the whole cache, but it doesn't block shutdown until all entries are deleted.

(In reply to Michal Novotny (:michal) from comment #6) > Clearing cache on shutdown works correctly in Firefox. Not with my one. I will try a newly created User Profile

(In reply to Michal Novotny (:michal) from comment #6) > Clearing cache on shutdown works correctly in Firefox. The reason why it > doesn't work in Seamonkey is that it calls nsICacheStorageService::clear() > instead of setting "privacy.clearOnShutdown.cache" preference to true. > nsICacheStorageService::clear() starts evicting the whole cache, but it > doesn't block shutdown until all entries are deleted. So here is what i could observe (my spare time is very limited at the moment): We are talking about FF 49.0.1 here, EN-US 1. If FF is set to "Never remember history" it won't delete any preexisting cache entries/folders. 2. If FF is set to use custom settings (no private browsing) during the session and "Clear history when Firefox closes" is does erase the whole content of the cache2 folder. 3. If FF is set to "always use private browsing" it will not create any subfolders in cache 2, but there are some files written per page impression which are then deleted on shutdown. What are those files? Comment4 said you don't store anything. So Nr. 1 seems to be a small problem/misunderstanding, as a user would assume FF will delete those entries even if they aren't from this session.

(In reply to Michal Novotny (:michal) from comment #6) > Clearing cache on shutdown works correctly in Firefox. Further tests confirm Michal's assumption that clearing cache works fine, I was not able reproduce my observations in comment 5. Today and yesterday I did several tests with FF and my default user profile, an old user profile not used since 2012 and a newly created one. Always "\cache2\entries" and "\cache2\doomed" was deleted correctly during shutdown. I have no doubt that I observed a real cache deletion problem during my tests for Comment 5, but that can not be the same problem like the one in SM So back to Product=SeaMonkey

@hallobox Please file a new bug report for your observations in comment 8