Inform disk cache of WebKit memory cache hits.

content/common/view_messages.h

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 // IPC messages for page rendering.
 // Multiply-included message file, hence no include guard.
 
 #include "base/process.h"
 #include "base/shared_memory.h"
 #include "content/common/common_param_traits.h"
@@ skipping 1395 matching lines @@
                     int32 /* page_id */)
 
 // Sent when the renderer loads a resource from its memory cache.
 // The security info is non empty if the resource was originally loaded over
 // a secure connection.
 // Note: May only be sent once per URL per frame per committed load.
 IPC_MESSAGE_ROUTED2(ViewHostMsg_DidLoadResourceFromMemoryCache,
                     GURL /* url */,
                     std::string  /* security info */)
 
+// Sent when the renderer accesses a resource in its memory cache. Used to
+// synchronize the disk cache with the memory cache.
+IPC_MESSAGE_CONTROL2(ViewHostMsg_DidAccessResourceInMemoryCache,

[darin (slow to review), 2011/07/30 05:09:32]

it slightly bugs me that we have DidLoadResourceFromMemoryCache and
DidAccessResourceInMemoryCache.  those sound like synonyms, and it seems odd
that we should need to inform the browser twice about the same event.

i understand that you are doing this because one is a routed message and the
other is a control message.  one is handled on the UI thread of the browser and
the other is handled on the IO thread of the browser.

unfortunately, we do not have good infrastructure for intercepting a message
bound for the browser's UI thread, inspecting the message, and then letting the
message proceed on to the UI thread.  we have IPC MessageFilter which can be
used to intercept the IPCs on the IO thread, but that terminates the handling of
the IPC.

ideally, just piggy back on ViewHostMsg_DidLoadResourceFromMemoryCache for this
feature.  in the IO thread, we'd intercept the IPC, act on it, and then let the
IPC continue on to the UI thread.

maybe this is something to explore in the future?  but maybe there is an easy
way to do this now?

edit: jam points out that MessageFilter::OnMessageReceived can return false to
allow the message to be normally processed!

+                     GURL /* url */,
+                     std::string /* http method */)
+
 // Sent when the renderer displays insecure content in a secure page.
 IPC_MESSAGE_ROUTED0(ViewHostMsg_DidDisplayInsecureContent)
 
 // Sent when the renderer runs insecure content in a secure origin.
 IPC_MESSAGE_ROUTED2(ViewHostMsg_DidRunInsecureContent,
                     std::string  /* security_origin */,
                     GURL         /* target URL */)
 
 // Sent when the renderer starts a provisional load for a frame.
 IPC_MESSAGE_ROUTED4(ViewHostMsg_DidStartProvisionalLoadForFrame,
@@ skipping 570 matching lines @@
 
 IPC_MESSAGE_ROUTED3(ViewHostMsg_SendCurrentPageAllSavableResourceLinks,
                     std::vector<GURL> /* all savable resource links */,
                     std::vector<GURL> /* all referrers of resource links */,
                     std::vector<GURL> /* all frame links */)
 
 IPC_MESSAGE_ROUTED3(ViewHostMsg_SendSerializedHtmlData,
                     GURL /* frame's url */,
                     std::string /* data buffer */,
                     int32 /* complete status */)