Browser cache not saved anymore, (profile related...)

VERIFIED FIXED in seamonkey2.1a1

Status

SeaMonkey
General
--
major
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Sven Grull, Assigned: Biesinger)

Tracking

({regression})

Trunk
seamonkey2.1a1
x86
Windows XP
regression
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [fixed by bug 531801])

(Reporter)

Description

8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100221 Lightning/1.1a1pre SeaMonkey/2.1a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100221 Lightning/1.1a1pre SeaMonkey/2.1a1pre

The browser cache is not saved to disk anymore with SeaMonkey tinderbox trunk builds. There are no files saved to the cache folder in my profile while browsing.
This also happens in safe-mode. Firefox tinderbox trunk builds are not affected.

Reproducible: Always
(Reporter)

Comment 1

8 years ago
Regression window:
last good:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100212 Lightning/1.1a1pre SeaMonkey/2.1a1pre

first bad:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a2pre) Gecko/20100213 Lightning/1.1a1pre SeaMonkey/2.1a1pre

The only files that are created in the cache folder starting with 20100213 are _CACHE_001_ _CACHE_002_ _CACHE_003_ and _CACHE_MAP_
Keywords: regression
Version: unspecified → Trunk
Pushlog for mozilla-central: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-02-12&enddate=2010-02-13+03%3A00%3A00
Pushlog for comm-central: http://hg.mozilla.org/comm-central/pushloghtml?startdate=2010-02-12&enddate=2010-02-13+03%3A00%3A00
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.3a2pre) Gecko/20100220 SeaMonkey/2.1a1pre] (nightly) (W2Ksp4)

With a new profile, I got the 4 '_CACHE_*_' files + a few cache files like '4307F78Cd01'.
WorksForMe...

Could you double-check and provide more details as needed?
(Reporter)

Comment 4

8 years ago
I just did another try with tinderbox build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a3pre) Gecko/20100305 Lightning/1.1a1pre SeaMonkey/2.1a1pre
I still see the same behavior there are no cache entries saved. I tried to change the cache prefs but that had no effect.
Also in safe-mode there are no files written to the cache. I checked this also via about:cache. Number of entries for disk cache is always 0.
With a new profile the files are saved to browser cache. 
Going back to 20100212 the problem is gone again and files are saved to cache with my old profile.
(In reply to comment #4)
> With a new profile the files are saved to browser cache. 

Ah! (NB: You're supposed to check that when filing bugs...)
From comment 2, only bug 531801 would seem related!?
Please, test (with a new profile) to find out what is triggering this bug in your usual profile.
Summary: Browser cache not saved anymore → Browser cache not saved anymore, (profile related...)
(Reporter)

Comment 6

8 years ago
(In reply to comment #5)

> From comment 2, only bug 531801 would seem related!?
> Please, test (with a new profile) to find out what is triggering this bug in
> your usual profile.

This bug indeed depends on bug 531801. Setting browser.cache.disk_cache_ssl to true solves the problem with my old profile and files are saved to disk again, both http and https based files.
Depends on: 531801
(Reporter)

Comment 7

8 years ago
This problem does only happen with SeaMonkey. My profile for Firefox trunk has also set browser.cache.disk_cache_ssl to false and files are saved to disk cache.
Blocks: 531801
No longer depends on: 531801
Fixed by followup checkin for bug 531801.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Assignee: nobody → cbiesinger
Flags: in-testsuite-
Whiteboard: [fixed by bug 531801]
Target Milestone: --- → seamonkey2.1a1
(Reporter)

Comment 9

8 years ago
Verified fixed with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a3pre) Gecko/20100309 Lightning/1.1a1pre SeaMonkey/2.1a1pre
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.