[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.
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.
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.
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.
per adt, not critical for nsbeta1. hence minus.
FWIW: changing the Memory Cache size shows the same behavior.
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.
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.
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.
Comment on attachment 102234 [details] [diff] [review] proposed fix sr=darin
Fix checked in.
Verified with 2002-10-10-00.