I have not been able to come up with a reproducable test case for this yet. What i am experiencing is this, on occasion when autoconfig is activated the browser will launch using cached data instead of the data which is currently on the server. This will occur even when the failover.jsc and the prefs.js files have been removed, which leads me to believe that the AutoConfig info is being stored in the disk or memory cached. This theory is supported by the fact that on the occasions which i have successfully reproduced this bug, i was able to "fix" it by clearing my cache. The only steps which i have to reproduce this bug are 1. Edit netscape.cfg to use the autoconfig server. 2. Launch netscape 3. Quit netscape, modify data on server. 4. Launch netscape. Usually the expected result occurs, which is that the new info is used.

I think the solution would be to disable loading from the cache of autoconfig.jsc.

Your logic seems reasonable. Caching the file would cause this problem. Could you maybe use the autoadmin.refresh_interval pref to test the caching theory? You could change the server between refreshes and see if it picks it up.

assigning QA to lrg.

I could reproduce the bug by changing the filename on the server. Browser uses the cached copy when it doesn't find the file on the server. when I edited the cached copy by hand, it uses the new values. It happens with the timer interval and it also happens when you restart the browser. After applying the patch, it doesn't use cached copy. But it still generates one. When I changed the flag from INHIBIT_CACHING to INHIBIT_PERSISTENT_CACHING, it doesn't generate a cached copy. I will change the flag in the next patch. By inhibiting caching, we will save some startup time. Because, this is the first time a network connection is made so it has to initialize the cache.

I don't know too much about this, but it seems like a good idea and code is safe..sr=alecf

My gut reaction is that caching the .jsc file is just wrong anyway. r=bnesse.

a=blizzard for drivers for the trunk

Code checked in

Tinderbox is fine

Marking target as mozilla0.9.2.

Verified that the fix works in both the trunk (0626) and the branch (0625) on Win32, linux and MacOS.