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.
Status: NEW → ASSIGNED
Priority: -- → P3
Target Milestone: --- → mozilla0.9.9
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.
Created attachment 60757 [details] [diff] [review] v1.0 patch 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.
Priority: P3 → P2
Comment on attachment 60757 [details] [diff] [review] v1.0 patch this patch causes FinalizeCacheEntry to sometimes not run. ugh!
Attachment #60757 - Flags: needs-work+
Created attachment 67891 [details] [diff] [review] v1.1 patch this patch solves the problem more directly
Attachment #60757 - Attachment is obsolete: true
Comment on attachment 67891 [details] [diff] [review] v1.1 patch r=gagan
Attachment #67891 - Flags: review+
Comment on attachment 67891 [details] [diff] [review] v1.1 patch sr=mscott
Attachment #67891 - Flags: superreview+
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.