343747 - bfcache should only cache documents where the channel implements nsICachingChannel

Status: UNCONFIRMED

(Core :: DOM: Navigation, defect)

Description

[Bill Filler]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

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 <[e-mail]> 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

Comment 1

[Thomas Bertels]

Is this still reproduceable with Firefox 3/with a trunk version ?

Comment 2

[Shawn Wilsher :sdwilsh]

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).

Comment 3

[Boris Zbarsky [:bzbarsky]]

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.

Comment 4

[Graham Perrin]

Time to close?