48477 - Stopping a page mid-load doesn't finish loading next time page is accessed

Status: VERIFIED FIXED

(Core :: Networking: Cache, defect, P3)

Description

[Mike Pinkerton (not reading bugmail)]

- launch mozilla
- go to cnn.com, but before all the images come in, click "Stop" button
- quit app
- launch mozilla again
- go to cnn

Expected results:
- page fully loads

Actual results:
- page loads only as far as when you clicked the stop button, eg, images that 
weren't loaded don't come in and the page thinks it has finished.

Clicking the "reload" button refreshes and reloads the entire page correctly.

Comment 1

[Mike Pinkerton (not reading bugmail)]

annonying, but not dogfood. certainly needs to be fixed for beta3.

Comment 2

[Gagan]

Seems like we are not checking for a good status in the OnStop coming from the
socket transport. This should be a small fix. plus. 

Comment 3

[Suresh Duddi (gone)]

Maybe we should do something like

ResponseCompleted()
	if (partialFlag is set and mCacheTransport && was STOPPED) {
		// we are the only user writing to the cache entry
		// and we didn't complete
		invalidate the entry.
	}

Comment 4

[Suresh Duddi (gone)]

Ok found the reproducible case for this. It doesn't have to be stoping mid-load.

Nav start - cache::b.html(182 bytes), b.html(205 bytes)
Visit b.html caused b.html to be fetched from server. LogicalLength 
becomes 205. But the entry isn't flushed to disk. Hence the 
contentLength (disk cache file size) is still 182 bytes.

nsHTTPChannel::ResonseComplete() has this contentLength hack that gets 
trigggered only if (contentLength > logicalLength) which isn't true. 
Hence we dont update contentLength (cant rather).

Next we modify b.html to 190 bytes. Then hit reload. This causes 
LogicalLength to become 190 bytes. We hit 
nsHTTPChannel::ResponceComplete() and our hack of (contentLength > 
logicalLength) is comparing (182 > 190) which is false and hence 
contentlength stays at 182.

So what is wrong here: I dont believe the file is being updated. Esp 
since calls to GetStoredContentLength() is accessing the mFile, we have 
to keep the file in sync as soon as possible with the cacheentry.

What do you people think ? Does this all sound like a possible explanation.

And the bug was so hard to reproduce because if the file changed size to 
less than its size on cache before modification, in this case, less than 
182 (the initial size of the disk cache entry before start), then the 
cache would get updated properly and we wont see the bug. The only 
sequence to reproduce it is:
- file already in cache before start with size A
- modify file after start to size B (B > A)
- modify file again to size C (A < C < B).

Comment 5

[Suresh Duddi (gone)]

This might a different bug. I am reopening another for where the contentLength 
gets messed up as described above. bug 50922

Comment 6

[Suresh Duddi (gone)]

We fixed a couple of other bugs in this area. We release cache entries as soon 
as possible. We flush cache entries to disk as soon as possible.

Those should have fixed this. Markings so for verification.

Comment 7

[Tom Everingham]

verified:
Mac 2000090704

Comment 8

[Michael Lefevre]

fixing null OS field on old bugs