User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:220.127.116.11) Gecko/20060508 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:22.214.171.124) Gecko/20060508 Firefox/126.96.36.199 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 <email@example.com> 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
Component: History → Bookmarks & History
QA Contact: history → bookmarks
Is this still reproduceable with Firefox 3/with a trunk version ?
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).
Status: UNCONFIRMED → RESOLVED
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INCOMPLETE → ---
Version: 1.8 Branch → Trunk
Time to close?
You need to log in before you can comment on or make changes to this bug.