If you hit the stop button and we have several urls queued up waiting to get run, we currently don't doom the cache entries (if any) associated with these queued urls. This could lead to a scenario where we then think we have a valid cache entry for a message. Reading from that cache entry gives you a blank message. This spun off from Bug #114571
We've had a bunch of bugs regarding messages not displaying correctly after hitting stop or switching messages and come back. This is the type of bug we've been nsbeta1+'ing. But, how likely is it that we'll hit the scenario that would require this bug to be fixed in order for this to work?
Status: NEW → ASSIGNED
Has this been implemented since 1.2.1? If so this is not a good solution - it is causing major performance problems on web pages with that version and 1.3a since everything that is valid in the cache is deleted if I click a link to browse to another URL before the page load completes. It also defeats the purpose of even having partial transfers be able to resume since those partial transfers are being doomed along with the rest of the valid cached content.
I should point out that is applies to standard web browsing - not email. I did a log of the HTTP protocol code and aborting a web page load causes all content that wasn't fully transfered yet (or has not even started to transfer) to get marked as doomed. The crux of the problem is or around line 1346 of nsHttpChannel.cpp. There needs to be more checked on whether to doom an entry or not.
this bug has absolutely nothing to do with web browsing - it's strictly to do with mail's use of the memory cache. This was fixed, I believe, a while ago.
*** Bug 220633 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.