679296 - a disk cached resource is not memory cached when in private browsing

Status: RESOLVED INVALID

(Core :: Networking: Cache, defect)

Description

[al_9x]

since the disk cache is not used in private browsing, it should not affect private browsing memory caching

1. Fx 6 - 8.0a1 (2011-08-15), new profile
2. start with about:home
3. clear everything
4. start private browsing
5. load a static resource
http://www.mozilla.org/images/template/screen/logo_footer.png
6. check about:cache?device=memory it's fully cached (data size > 0)
7. restart
8. clear everything
9. load the resource
10. start private browsing
11. load the resource
12. check about:cache?device=memory the entry is present but only the headers are cached, data size is 0

Comment 1

[Josh Matthews [:jdm]]

PB explicitly evicts all cache entries stored anywhere at the moment. We could theoretically change this to evict all STORE_IN_MEMORY entries followed by STORE_OFFLINE.

Comment 2

[al_9x]

(In reply to Josh Matthews [:jdm] from comment #1)
> PB explicitly evicts all cache entries stored anywhere at the moment.

Not sure I understand how this explanation accounts for what I am reporting, please expand and clarify.  PB fails to memory cache a resource (after it's loaded in PB) if it happens to be cached to disk, why?

Comment 3

[Josh Matthews [:jdm]]

When exiting, PB currently tells the cache service to evict all entries regardless of their storage medium. I'm saying that it is possible to change this to implement your original suggestion.

Comment 4

[al_9x]

(In reply to Josh Matthews [:jdm] from comment #3)
> When exiting, PB currently tells the cache service to evict all entries
> regardless of their storage medium.

I don't think you have understood the problem, this bug manifests before exiting PB.
 
1. start with about:home
2. clear everything
3. load the resource (it gets disk cached)
4. start private browsing
5. load the resource
6. check about:cache?device=memory the entry is present but only the headers are cached, data size is 0

there is no exiting in the above steps

Comment 5

[Josh Matthews [:jdm]]

You're right, my mistake. The relevant cache clearing code that runs on entering/existing is also in the cache service, not the private browsing service. It appears to explicitly evict all entries in the memory cache device, not any of the others.

Comment 6

[(no longer active)]

Jason, can you suggest a Necko guru to take a look at this, please?

Comment 7

[Jason Duell]

Michal's doing the private browsing + cache interaction, so I'm assuming this is for him.

Comment 8

[Michal Novotny [:michal]]

The cache entry is empty because the image is taken from image cache and loading of nsHttpChannel is canceled here:

#0  imgLoader::LoadImageWithChannel (this=0xf6072820, channel=0xe3ee3034, aObserver=0xf17547c0, aCX=0xe3f6b800, listener=0xe3e6bbf0, _retval=
    0xf17547c4) at /opt/moz/hg/modules/libpr0n/src/imgLoader.cpp:1894
#1  0x01a01d89 in nsImageLoadingContent::LoadImageWithChannel (this=0xf17547c0, aChannel=0xe3ee3034, aListener=0xe3e6bbf0)
    at /opt/moz/hg/content/base/src/nsImageLoadingContent.cpp:571
#2  0x01bf3210 in mozilla::dom::ImageListener::OnStartRequest (this=0xe3e6bbe0, request=0xe3ee3034, ctxt=0x0)
    at /opt/moz/hg/content/html/document/src/ImageDocument.cpp:240
#3  0x0237e135 in nsDocumentOpenInfo::OnStartRequest (this=0xe4048a00, request=0xe3ee3034, aCtxt=0x0)
    at /opt/moz/hg/uriloader/base/nsURILoader.cpp:304
#4  0x0148f1ab in nsHttpChannel::CallOnStartRequest (this=0xe3ee3000) at /opt/moz/hg/netwerk/protocol/http/nsHttpChannel.cpp:725
#5  0x014906c7 in nsHttpChannel::ContinueProcessNormal (this=0xe3ee3000, rv=0) at /opt/moz/hg/netwerk/protocol/http/nsHttpChannel.cpp:1211
#6  0x01490458 in nsHttpChannel::ProcessNormal (this=0xe3ee3000) at /opt/moz/hg/netwerk/protocol/http/nsHttpChannel.cpp:1148
#7  0x0148fe46 in nsHttpChannel::ProcessResponse (this=0xe3ee3000) at /opt/moz/hg/netwerk/protocol/http/nsHttpChannel.cpp:1002
#8  0x0149b7cb in nsHttpChannel::OnStartRequest (this=0xe3ee3000, request=0xe43f1940, ctxt=0x0)
    at /opt/moz/hg/netwerk/protocol/http/nsHttpChannel.cpp:4063
#9  0x013a2f4f in nsInputStreamPump::OnStateStart (this=0xe43f1940) at /opt/moz/hg/netwerk/base/src/nsInputStreamPump.cpp:441
#10 0x013a2d83 in nsInputStreamPump::OnInputStreamReady (this=0xe43f1940, stream=0xe414d5bc)
    at /opt/moz/hg/netwerk/base/src/nsInputStreamPump.cpp:397
#11 0x029c7850 in nsInputStreamReadyEvent::Run (this=0xe3f3f260) at /opt/moz/hg/xpcom/io/nsStreamUtils.cpp:114
#12 0x029e8149 in nsThread::ProcessNextEvent (this=0xf753ba80, mayWait=0, result=0xff97224c) at /opt/moz/hg/xpcom/threads/nsThread.cpp:631
#13 0x0297e638 in NS_ProcessNextEvent_P (thread=0xf753ba80, mayWait=0)
    at /opt/moz/hg/_obj-browser-release-tb-fp-dbg/xpcom/build/nsThreadUtils.cpp:245

Comment 9

[(no longer active)]

Then shouldn't the image resource not be cached at all?  Does the right thing happen when the image is removed from the image cache, and another request is made for it (which might search inside the memory cache)?

Comment 10

[Michal Novotny [:michal]]

I thought that this should work because the entry would be then handled as partial entry. To be sure I wanted to test it but now I can't reproduce the problem anymore. The entry is doomed in nsHttpChannel::CloseCacheEntry().

Comment 11

[Michal Novotny [:michal]]

Closing again. The empty cache entry isn't doomed when the request is resumable. If the image is deleted from the image cache then the request is correctly handled as partially cached entry. The reason why I was not able to reproduce it later was that the server I used for testing has unexpectedly stopped sending "Accept-Ranges" in the response.