Closed Bug 113081 Opened 23 years ago Closed 22 years ago

Disk cache size not updated until mozilla is restarted.

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.0

People

(Reporter: andre.bugs2, Assigned: gordon)

Details

Attachments

(1 file)

[Build-ID: 2001-12-01-12 on Linux]

I think this is Linux-only, so there's no need to WFM it if you're on Windows:-)
The problem is that if you go to Edit->Preferences->Advanced->Cache and change
the value in the "Disk Cache" field that new value will not be used by mozilla
until you restart it. Steps to reproduce:

1) Go to Edit->Preferences->Advanced->Cache
2) Set "Disk Cache" to something different from it's current value.
3) Enter "about:cache" in the location bar.

Result: The "Maximum storage size:" under "Disk cache device" does still show
the old value.

Expected result: The new value should directly be used by mozilla, and displayed
by about:cache.
Target Milestone: --- → mozilla0.9.9
Conrad, it seems as though my observers don't get notified on Linux.  Any ideas?
Hmm, no. I can't see what would be not XP with that mechanism without stepping
through it.
Priority: -- → P2
Okay, it doesn't appear to be platform specific.  I can reproduce this problem
on my Mac as well as my Linux machine.

The problem is that if there is only one profile (or no profile, so that a
single default profile is used) then the "profile-after-change" notification
gets done *before* the cache service registers its observer.  If there are
multiple profiles, the profile picker window comes up, *after* the cache service
has installed its profile observer, and the cache service receives the
"profile-after-change" notification.

Conrad, how can the cache service tell if we currently have a profile? 
isCurrentProfileAvailable() appears to be deprecated.
OS: Linux → All
It would be nice for the pref change notifications not to have to depend on
whether there is a profile or not. You can use isCurrentProfileAvailable() but
that would introduce a module dependency on profile which is really bad. If
there's no way to make these notifications not depend on whether there is a
profile, you can use directory service to get the profile directory. That would
at least not have the module dependency problem.
Target Milestone: mozilla0.9.9 → mozilla1.0
Keywords: nsbeta1
per adt, not critical for nsbeta1. hence minus.
Keywords: nsbeta1nsbeta1-
FWIW: changing the Memory Cache size shows the same behavior.
Keywords: mozilla1.1
Hardware: PC → All
This appears to be fixed.  The code was actually already following Conrad's
advice.  Perhaps there was a problem with profile observer notifications after
all, which has been fixed in the mean time.

Is anybody still seeing this problem?
I can still reproduce it using the original mentioned steps. This is with
2002-10-03-08 on Linux.
Attached patch proposed fixSplinter Review
When there is only a single profile or the profile is specified on the command
line, the cache is initialized after the profile service, so we don't get the
profile-after-change notification.  To cover that case, I'm adding code to
query the directory service for NS_APP_USER_PROFILE_50_DIR, which indicated the
presence of a profile.
The problem was we weren't reading the updated prefs because we thought we
didn't have a profile, and we were wait for a profile-after-change notification
so we could read all the prefs in at once.
Comment on attachment 102234 [details] [diff] [review]
proposed fix

r=bnesse.
Attachment #102234 - Flags: review+
Comment on attachment 102234 [details] [diff] [review]
proposed fix

sr=darin
Attachment #102234 - Flags: superreview+
Fix checked in.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Verified with 2002-10-10-00.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: