If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Disk cache size not updated until mozilla is restarted.

VERIFIED FIXED in mozilla1.0



Networking: Cache
16 years ago
15 years ago


(Reporter: André Dahlqvist, Assigned: gordon)



Firefox Tracking Flags

(Not tracked)



(1 attachment)

1.07 KB, patch
Brian Nesse (gone)
: review+
Darin Fisher
: superreview+
Details | Diff | Splinter Review


16 years ago
[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.


16 years ago
Target Milestone: --- → mozilla0.9.9

Comment 1

16 years ago
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.


16 years ago
Priority: -- → P2

Comment 3

16 years ago
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.


16 years ago
Target Milestone: mozilla0.9.9 → mozilla1.0


16 years ago
Keywords: nsbeta1

Comment 5

16 years ago
per adt, not critical for nsbeta1. hence minus.
Keywords: nsbeta1 → nsbeta1-

Comment 6

16 years ago
FWIW: changing the Memory Cache size shows the same behavior.


16 years ago
Keywords: mozilla1.1
Hardware: PC → All

Comment 7

15 years ago
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?

Comment 8

15 years ago
I can still reproduce it using the original mentioned steps. This is with
2002-10-03-08 on Linux.

Comment 9

15 years ago
Created attachment 102234 [details] [diff] [review]
proposed fix

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.

Comment 10

15 years ago
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 11

15 years ago
Comment on attachment 102234 [details] [diff] [review]
proposed fix

Attachment #102234 - Flags: review+

Comment 12

15 years ago
Comment on attachment 102234 [details] [diff] [review]
proposed fix

Attachment #102234 - Flags: superreview+

Comment 13

15 years ago
Fix checked in.
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 14

15 years ago
Verified with 2002-10-10-00.
You need to log in before you can comment on or make changes to this bug.