Handle two cases that we previously weren't expecting.

The first is inside GCF where we get a tab message after the target tab has been torn down.
Before, we set handled to 'false' which would cause the message to end up in AutomationProxy which doesn't know how to handle it.  The fix is to drop the message and treat it as handled.

The second is when we attempt to send a download request to the host browser but the request has already been terminated.
We treated this as a fatal error, but now only log an error.

TEST=See repro steps in bug.
BUG=69595

Review URL: http://codereview.chromium.org/6260009

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

chrome/browser/automation/automation_resource_message_filter.cc

@@ -403,7 +403,7 @@ bool AutomationResourceMessageFilter::SendDownloadRequestToHost(
   int automation_request_id = 0;
   bool valid_id = GetAutomationRequestId(request_id, &automation_request_id);
   if (!valid_id) {
-    NOTREACHED() << "Invalid request id: " << request_id;
+    LOG(ERROR) << "Invalid request id: " << request_id;
     return false;
   }
 

chrome_frame/chrome_frame_automation.cc

@@ -79,6 +79,8 @@ class ChromeFrameAutomationProxyImpl::TabProxyNotificationMessageFilter
       tab->Release();
     } else {
       DLOG(ERROR) << "Failed to find TabProxy for tab:" << message.routing_id();
+      // To prevent subsequent crashes, we set handled to true in this case.
+      handled = true;
     }
     return handled;
   }