bfcache should only cache documents where the channel implements nsICachingChannel




Document Navigation
12 years ago
4 months ago


(Reporter: Bill Filler, Unassigned)



Firefox Tracking Flags

(Not tracked)




12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20060508 Firefox/

I've written a custom protocol handler that is being used in
my embedding application. There seems to be no way for the protocol handler to
mark it's returned content stale or expired so that when the content
is accessed via nsIWebNavigation::goBack() and goForward() it can be reloaded.
So my pages always show up in the history correctly, but never get reloaded when I use the back/forward mechanisms, instead the cached version is displayed.

Here are comments from Christian Biesinger <> with a proposed solution/workaround:

Hrm, true, bfcache caused that problem... Before it, protocol handlers 
had to explicitly handle cache stuff.

Maybe bfcache should only be enabled for channels that QI to 
nsICachingChannel; it might be a good idea to file a bug about that.
Urg, apparently this code just always caches all non-HTTP channels. That 
kind of sucks.
I guess the only solution that works in existing versions is to 
implement nsIHttpChannel and return true from isNoStoreResponse. This is 
not a great solution though. You should file a bug on providing a better 
one, maybe that'd just be what I suggested above (make bfcache only 
cache documents where the channel implements nsICachingChannel)

Reproducible: Always

Steps to Reproduce:
1. write a custom protocol handler whose channel implements nsIChannel
2. load some pages in the browser that use the custom protocol
3. use the back/forward browser buttons and cached versions of the pages are always displayed. No way to reload the page


11 years ago
Version: unspecified → 1.5.0.x Branch


10 years ago
Component: History → Bookmarks & History
QA Contact: history → bookmarks

Comment 1

10 years ago
Is this still reproduceable with Firefox 3/with a trunk version ?
Blocks: 274784
Bulk closing all UNCONFIRMED bugs dealing with places that haven't had any bug activity in over 120 days, have no votes, and are not enhancement requests.

If you are still experiencing this issue in Firefox 3.0 or later, please re-open the bug with steps to reproduce (if they were not part of the original comment).
Last Resolved: 10 years ago
Resolution: --- → INCOMPLETE
Component: Bookmarks & History → Document Navigation
Product: Firefox → Core
QA Contact: bookmarks → docshell
Version: 1.5.0.x Branch → 1.8 Branch
Uh... So this has nothing to do with Places.

That said, I think that bfcache caching file://, data:, etc is actually a good idea.  Maybe we should add a protocol flag for protocols that don't want to be bfcached?

But even past that, I can't think of a reason why I'd want to not get exactly what I saw when doing history navigation.  We don't that for HTTP in some cases for security reasons, but I'd rather not expand that behavior any more than we have to.
Resolution: INCOMPLETE → ---
Version: 1.8 Branch → Trunk

Comment 4

4 months ago
Time to close?
You need to log in before you can comment on or make changes to this bug.