Ahh, yet another lesson learned the hard way and posted here to save a few hours in someone's future.
This particular lesson was about caching and various browsers and a solution that has been known by many for a long time, just not me! :-)
I am using ASP.NET Control Adapters to alter the default html which ASP.NET normally renders for DataLists and TreeView controls.
The adapters are set explicitly for the following browsers: IE6to9, MozillaFirefox, Opera8to9,Safari and even “W3C_Validator“.
Every once in a while, the adapted TreeView was displaying without it's new formatting or pretty CSS settings and it was ugly! Oddly, by programmatically clearing the cache fpr the page (here's how to do that!), I was able to force the page to render again with the correct output. So somehow some bad rendering was getting “stuck“ in the cache. But I couldn't figure out what was provoking this adapter-less rendering.
It took a while before I understood what was happening well enough to describe the problem in a way that someone finally went “aha! Here is your problem.“
The problem was that I was not caching based on browser. This can be done using the OutputCache directive with VaryByCustom set to browser.
<% @ OutputCache VaryByParm=“none“ VaryByCutom=“browser“ %>
<% @ OutputCache VaryByParam=“none“ VaryByCustom=“browser“ %>
Without this setting, a new browser coming along, such as a Mobile web browser, would pull down a non-adapted version of the treeview and that would stay in the cache. So when I.E. or FireFox came back along to browse the page, they were stuck with the other version. I don't quite get the inner inner details of how that was happening - why did the mobile web browser pull a new page into the cache, when I.E. couldn't.
Either way, adding that parameter in has fixed the problem as far as I can tell since I haven't seen it again yet in nearly three weeks.
Thanks to Bertrand for the “aha!“.