57463 - Cache not created until second run of new profile

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect, P3)

Description

[John Morrison]

This is split off from an observation made in bug 54097

   ------- Additional Comments From John Morrison 2000-10-19 21:36 -------
   
   [By the way, I then retried on a brand new profile, and found that the
   cache is not created until the second run of the browser (that is with
   either the trunk or branch 10/19 builds). I'll go find out if this is a
   known problem.]
   
   ------- Additional Comments From John Morrison 2000-10-19 21:39 -------
   
   [Sorry, just want to be clear ... the "cache-only-on-second-run" happens
   for an install into a "slash-less" folder name, as well as installation
   into '...:foo/test'. This problem is independent of having a slash in
   the folder name].
   
   ------- Additional Comments From Conrad Carlen 2000-10-20 10:33 -------
   
   John, you're right about the cache not getting made until 2nd run. I
   installed 2000101908 MTrunk also into "HD:foo:foo/test" and did not get
   a cache until the second run. That cache problem is unrelated to this
   bug for certain. Although WRT this bug, I was able to relaunch again and
   again with a '/' in my path. Any more testers? How much more info is
   needed to go to rtm+?
   
   ------- Additional Comments From Simon Fraser 2000-10-20 12:05 -------
   
   cc neeti, for the "cache only on 2nd run" issue.
   
   ------- Additional Comments From [e-mail] 2000-10-20 15:02 -------
   
   On windows and linux, I find that the cache is made on the first run of
   the browser with a new profile. I do not have access to a Mac currently.
   
   Gordon,
   Can you investigate why we do not create the cache on the first run for
   a new profile on the Mac?
   
   Thanks,
   Neeti

Comment 1

[Conrad Carlen (not reading bugmail)]

Got this one figured out. It happens not with mozilla, only with NS6. The
difference is activation. In order for the disk cache to be used the preference
for its dir needs to be set. This pref is set up by InitializeCachePrefs in
nsAppRunner. The disk cache, which is inited first time there is network
activity, needs to read this pref. Activation, which uses necko and thus the
disk cache is inited, happens BEFORE InitializeCachePrefs is called. One way to
fix this is with prefs. When a pref is set, pref mgr calls a callback which the
client (necko disk cache) set up. It uses this mechanism. Problem is this
callback mechanism is called only when a pref changes and not when set for the
first time. If a pref is unset and then it is set, the callback should be
called. Given what I've seen, I really don't see how this could be Mac-specific.
The order of execution of InitializeCachePrefs and the init of the disk cache
must be the same, no?

Comment 2

[John Morrison]

Adding Bhuvan to cc: for Activation issues.

Comment 3

[John Morrison]

> Given what I've seen, I really don't see how this could be Mac-specific.

Just to confirm (since I stumbled into this on win2k): no this is not 
Mac-specific (happens on win2k and I would assume that linux must as well).

Comment 4

[gordon]

Cache pref/profile clean up is scheduled for 0.9.1

Comment 5

[gordon]

This doesn't appear to be a problem anymore. It has been fixed by either the
lazy initialization of the new disk cache, the fact that we now don't rely on
InitializeCachePrefs(), or the order of Activation has changed (it now seems to
occur after a profile has been picked - which makes more sense anyway).
Marking FIXED.

Comment 6

[John Morrison]

verified on mac/linux/win32 06/14 trunk builds -- the NewCache is created for 
a new profile at or about the time that the Activation window comes up. In 
a mozilla build, it gets created when the first http content is loaded into the 
browser window with a new profile.