With the disk cache enabled, it makes sense to allow users to see whats in there. There could be privacy concerns, as well as data in the cache that the user wants to retain/save. Enabling about:cache would allow inspection using the mail startpage, but few users would know how to use that method. Marked this blocking bug 451599, as that might be a good place to implement the UI About:cache currently works on branch (for the memory cache) gives invalid url on trunk.

Some notes: To enable this, we need to add "about" to NECKO_PROTOCOLS_DEFAULT in mail/confvars.sh If we enable it, we'll get about:cache and about:cache-entry (although links from about:cache to about:cache-entry won't be followed correctly), and we'll enable about:bloat if the build is built with ref count logging (e.g. debug). From what gozer tried, about:cache only works as the mail start page - opening in a dialog, it has no css/styles associated with it so comes up as just text on the screen. I would not expect this to become part of the main UI (like about:config is) - rather just as a hidden option for us to use for debugging problems/cache, on both release and debug builds. I do think we should enable it, as it'll yet further reduce the differences between what TB & FF build.

Agreed we don't need any UI for this, being able to set it as start page would do IMO. (Possibly some tester extension might want to add the UI.)

Much as I hate to say "I told you so"... oh, wait, that's not much at all. Told you we were going to want to build about :)

As a note, that makes the only difference of the Thunderbird default to the usual necko default be gopher, which is ~25K of code we're saving according to bug 388195 comment #31 and that bug has been proposing removal of that protocol for a while. I wonder if it may be worth a thought not overriding NECKO_PROTOCOLS_DEFAULT at all for getting nearer to using a pristine platform. But then, I guess neck defaults aren't changing often enough that our overriding those defaults creates any problems.

(In reply to comment #5) > As a note, that makes the only difference of the Thunderbird default to the > usual necko default be gopher, which is ~25K of code we're saving according to > bug 388195 comment #31 and that bug has been proposing removal of that protocol > for a while. I wonder if it may be worth a thought not overriding > NECKO_PROTOCOLS_DEFAULT at all for getting nearer to using a pristine platform. > But then, I guess neck defaults aren't changing often enough that our > overriding those defaults creates any problems. I think given the debate in that bug I wouldn't want to enable something to have a debate about removing it later, not that I think it'd really be used in Thunderbird (but Thunderbrowse for instance could potentially use it). Although I'm all for harmonising ourselves with core, I think something like this we can leave until we're ready to go all the way, as the actual effect in minimal, especially as its only going to change our config file (if it resulted in removing ifdefs from core, then I'd be more for it).

Well, about:cache does work now in the start page. I can now see that I have 468 entries in my disk cache, but that all folks. Clicking on "List Cache entries" asks for an application to open the file. (This might be a remnant from Myk Melez' application pane thingy that was never implemented on TB) If I then set the start page to: about:cache?device=disk I can now see the entries in the disk cache. If I want to examine one of them, I then get the "application required" popup. But, if I again alter my start page to that entry, for instance: about:cache-entry?client=HTTP&sb=1&key=http://www.nasa.gov/js/191704main_effects.js I see definitive info on the cached item. So bottom line is, the resource is pretty much useless. But there is always Thunderbird support software available (Firefox) Copying the TB cache into a Firefox profile works quite well. Requesting re-opening this bug.

(In reply to comment #7) > Clicking on "List Cache entries" asks for an application to open the file. > about:cache?device=disk - I can now see the entries in the disk cache. > If I want to examine one of them, I then get the "application required" popup. Confirming this behavior for Shredder/3.0b1pre (Windows; 20080827031724), the links are not functional and pointing to the executable as application does not have any effect.

Disk caching seems to have stopped working for me after updating to" Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) Gecko/20080828032200 Shredder/3.0b1pre ID:20080828032200

(In reply to comment #9) > Disk caching seems to have stopped working for me after updating to" > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a2pre) > Gecko/20080828032200 Shredder/3.0b1pre ID:20080828032200 It seems to be working fine here for me - I visited a new page and the disk cache count went up by an appropriate amount of items.

Works for me with yesterday's nightly build too (same as in comment#9), also after incremental update. The number of disk-cache items increases for each report after restarting. Getting back to comment #7, anything that could be done here to make about:cache more useful beyond showing the summary page at startup?

Ok it seems the cache was cleared (don't know how/why) It wasn't expire dates, because some of them were way out there. Working fine now. Will monitor.