nsHttpChannel blows away cache entries whenever a page load doesn't succeed. this means that, if a user loads a page from the cache and then stops the page load part way through, the page will be deleted from the cache. there's no need to do this, and moreover it specifically discourages callers from canceling page loads when the server response is a 304 when that would otherwise be a useful thing to do.

looks like this isn't a problem when the cache entry is opened only for reading, such as when we are offline. however, it is a problem for normal cached loads as well as 304 redirects. submitting a simple patch which should do the trick.

this may work... but it'll need to be tested carefully. i suspect it may cause problems for pages that set cache control headers via <meta> html tags.

upping priority

Comment on attachment 60757 [details] [diff] [review] v1.0 patch this patch causes FinalizeCacheEntry to sometimes not run. ugh!

this patch solves the problem more directly

Comment on attachment 67891 [details] [diff] [review] v1.1 patch r=gagan

Comment on attachment 67891 [details] [diff] [review] v1.1 patch sr=mscott

fixed-on-trunk

fixed-on-trunk (really!)