Monday, August 17, 2009

Annoying cache problem in FF3.0.x

"If it ain't broke, fix it till it is"
Of course nobody would do that intentionally, but what if something looks broken. Well then you might start throwing the kitchen sink at it and actually break it--that's my recent experience doing some SharePoint branding. I'm making changes to the CSS to overwrite the background image for the brand. It works fine in IE but it keeps showing the image I'm trying to overwrite in FF (3.0.13 in this case). So I waste a couple hours between trying variations and replicating the problem with a simple test case--having no idea it was a caching issue. But when I couldn't replicate the problem, I used a completely different computer and realized it looked fine there on the same version of FF. Argh! All that time down the drain on something that wasn't broken. Mind you, I did suspect caching at one point early on and cleared out all the cache and tried restarting FF. Now onto the research phase... After spending some quality time with google on this subject, it seems FF3 did have some caching issues. You can read about it here:

http://www.west-wind.com/Weblog/posts/469125.aspx

And here:

http://forums.mozillazine.org/viewtopic.php?f=25&t=673135&sid=7859918dca9a1722635e233ef6f401db

The bottom line--I tried everything I could think to do with FF to get it to stop caching (about:config browser.cache settings, clearing cache umpteen different ways, physically deleting cache files, appending url parameters onto the files in question) but couldn't break the back of the beast. The one thing that finally solved it was creating a new profile for FF and using that (as suggested by jscher2000 in that second link). Here's how:

http://kb.mozillazine.org/Creating_a_new_Firefox_profile_on_Windows

As for the root cause, I'm not sure. The various posting on this show it's pretty complicated--possibly involving interactions between thinks like the type of request (GET, POST), the transport (http versus https), the cache header settings, if you have other tabs open, and installed addins (especially FireBug). The nice thing about the additional profile is I can keep it plugin free--which may be why it solved the problem. Hopefully this won't be a problem anymore in FF 3.5.

Interestingly, using about:cache and FireBug, I was able to determine that the CSS file that didn't seem to be having any effect was in fact being downloaded. But when I looked at the computed CSS in FireBug, it wasn't showing the change. That doesn't necessarily mean it's FireBug causing it, but it could be the Heisenberg Uncertainty Principal is at play.

UPDATE
A coworker suggested I try Ctrl-Shift-R which is supposed to completely bypass cache. So I fired up the handy Tamper Data FireFox plugin since it shows the "Load Flags" of each requested URL (presumably FireFox's decision about what action it needs to take regarding the request URL--pull from cache, download, etc). A quick test of this on a blogger.com page showed that it did indeed eliminate most cached elements with a status of LOAD_BYPASS_CACHE. However, a few URLs, in this case images of type .png and .gif, still had a LOAD_ONLY_IF_MODIFIED status without any further followup showing up in Tamper Data. So while Ctrl-Shift-R does resolve most caching, it is still doesn't eliminate it completely.