Fix a crash seen in ChromeFrame when opening a non CF top level tab from a CF page.

This was a regression caused by the fix for bug http://code.google.com/p/chromium/issues/detail?id=168308
which was to not invalidate the protocol sink mapping for CF pages which are switched in from IE.

The crash in this case occurs because the protocol sink mapping is removed in the call to IInternetProtocol::Terminate
as this is treated as a ChromeFrame request. This is only a temporary CF url which eventually transitions to
the actual URL which  is opened in IE. For the curious we intercept IInternetProtocol::LockRequest and for
the special gcf://attach_external_tab requests we addref the protocol data and return without calling the original
LockRequest API. When UnlockRequest is invoked we rely on the protocol data mapping to exist to release the
protocol data and return without calling the original UnlockRequest API.

In this case the sequence is IInternetProtocol::LockRequest, IInternetProtocolRoot::Terminate followed by
IInternetProtocol::UnlockRequest. In our terminate handler we remove the protocol data mapping for the attach tab
request. When UnlockRequest is called we call the original API and end up crashing.

Fix is to not invalidate the protocol data mapping for attach tab requests.

A test for this is in the works by robertshield.

BUG=178415
R=robertshield
Review URL: https://chromiumcodereview.appspot.com/12395021

git-svn-id: svn://svn.chromium.org/chrome/trunk/src@185956 0039d316-1c4b-4281-b951-d872f2087c98

1 files changed, 16 insertions, 3 deletions

diff --git a/chrome_frame/protocol_sink_wrap.cc b/chrome_frame/protocol_sink_wrap.cc
index 7664117..d093984 100644
--- a/chrome_frame/protocol_sink_wrap.cc
+++ b/chrome_frame/protocol_sink_wrap.cc
@@ -871,9 +871,22 @@ STDMETHODIMP Hook_Terminate(InternetProtocol_Terminate_Fn orig_req,
                             IInternetProtocol* protocol,
                             DWORD options) {
   scoped_refptr<ProtData> prot_data = ProtData::DataFromProtocol(protocol);
-  // TODO(ananta/robertshield)
-  // Write a test for this bug http://crbug.com/178421
-  if (prot_data && !IsChrome(prot_data->renderer_type()))
+  // We should not be invalidating the cached protocol data in the following
+  // cases:-
+  // 1. Pages which are switching into ChromeFrame.
+  //    When IE switches into ChromeFrame, we report the Chrome mime type as
+  //    the handler for the page. This results in urlmon terminating the
+  //    protocol. When Chrome attempts to read the data we need to report the
+  //    cached data back to Chrome.
+  // 2. For the attach external tab requests which are temporary navigations
+  //    to ensure that a top level URL is opened in IE from ChromeFrame.
+  //    We rely on the mapping to identify these requests as attach tab
+  //    requests. This mapping is referred to in the
+  //    IInternetProtocol::LockRequest/IInternetProtocol::UnlockRequest
+  //    intercepts. Invalidating the mapping after LockRequest is called and
+  //    before UnlockRequest causes IE to crash.
+  if (prot_data && !IsChrome(prot_data->renderer_type()) &&
+      !prot_data->is_attach_external_tab_request())
     prot_data->Invalidate();
 
   // We are just pass through at this point, avoid false positive crash