Revert 81175 since as kbr pointed out, this would break GPU in the meantime since an errory reply would be sent. I'll wait a week before relanding this.

Reland r79470 and disable the failing GPU test (and prerendering tests that use GPU) for now, so we don't get any more deadlock regressions.TBR=brettwReview URL: http://codereview.chromium.org/6822034
TBR=jam@chromium.org
Review URL: http://codereview.chromium.org/6824062

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

3 files changed, 19 insertions, 36 deletions

diff --git a/content/browser/browser_message_filter.cc b/content/browser/browser_message_filter.cc
index cd97a73..eaf6d0d 100644
--- a/content/browser/browser_message_filter.cc
+++ b/content/browser/browser_message_filter.cc
@@ -9,7 +9,6 @@
 #include "base/process_util.h"
 #include "chrome/browser/metrics/user_metrics.h"
 #include "content/common/result_codes.h"
-#include "ipc/ipc_sync_message.h"
 
 BrowserMessageFilter::BrowserMessageFilter()
     : channel_(NULL), peer_handle_(base::kNullProcessHandle) {
@@ -68,9 +67,6 @@ bool BrowserMessageFilter::OnMessageReceived(const IPC::Message& message) {
   if (thread == BrowserThread::IO)
     return DispatchMessage(message);
 
-  if (thread == BrowserThread::UI && !CheckCanDispatchOnUI(message, this))
-    return true;
-
   BrowserThread::PostTask(
       thread, FROM_HERE,
       NewRunnableMethod(
@@ -94,28 +90,3 @@ bool BrowserMessageFilter::DispatchMessage(const IPC::Message& message) {
 void BrowserMessageFilter::BadMessageReceived() {
   base::KillProcess(peer_handle(), ResultCodes::KILLED_BAD_MESSAGE, false);
 }
-
-bool BrowserMessageFilter::CheckCanDispatchOnUI(const IPC::Message& message,
-                                                IPC::Message::Sender* sender) {
-#if defined(OS_WIN)
-  // On Windows there's a potential deadlock with sync messsages going in
-  // a circle from browser -> plugin -> renderer -> browser.
-  // On Linux we can avoid this by avoiding sync messages from browser->plugin.
-  // On Mac we avoid this by not supporting windowed plugins.
-  if (message.is_sync() && !message.is_caller_pumping_messages()) {
-    // NOTE: IF YOU HIT THIS ASSERT, THE SOLUTION IS ALMOST NEVER TO RUN A
-    // NESTED MESSAGE LOOP IN THE RENDERER!!!
-    // That introduces reentrancy which causes hard to track bugs.  You should
-    // find a way to either turn this into an asynchronous message, or one
-    // that can be answered on the IO thread.
-    NOTREACHED() << "Can't send sync messages to UI thread without pumping "
-        "messages in the renderer or else deadlocks can occur if the page "
-        "has windowed plugins! (message type " << message.type() << ")";
-    IPC::Message* reply = IPC::SyncMessage::GenerateReply(&message);
-    reply->set_reply_error();
-    sender->Send(reply);
-    return false;
-  }
-#endif
-  return true;
-}
diff --git a/content/browser/browser_message_filter.h b/content/browser/browser_message_filter.h
index 621067b..e557dfd 100644
--- a/content/browser/browser_message_filter.h
+++ b/content/browser/browser_message_filter.h
@@ -48,11 +48,6 @@ class BrowserMessageFilter : public IPC::ChannelProxy::MessageFilter,
   // Can be called on any thread, after OnChannelConnected is called.
   base::ProcessHandle peer_handle() { return peer_handle_; }
 
-  // Checks that the given message can be dispatched on the UI thread, depending
-  // on the platform.  If not, returns false and an error ot the sender.
-  static bool CheckCanDispatchOnUI(const IPC::Message& message,
-                                   IPC::Message::Sender* sender);
-
  protected:
   // Call this if a message couldn't be deserialized.  This kills the renderer.
   // Can be called on any thread.
diff --git a/content/browser/renderer_host/render_view_host.cc b/content/browser/renderer_host/render_view_host.cc
index ffa2492..1f35dc3 100644
--- a/content/browser/renderer_host/render_view_host.cc
+++ b/content/browser/renderer_host/render_view_host.cc
@@ -29,7 +29,6 @@
 #include "chrome/common/spellcheck_messages.h"
 #include "chrome/common/translate_errors.h"
 #include "chrome/common/url_constants.h"
-#include "content/browser/browser_message_filter.h"
 #include "content/browser/child_process_security_policy.h"
 #include "content/browser/content_browser_client.h"
 #include "content/browser/cross_site_request_manager.h"
@@ -699,8 +698,26 @@ bool RenderViewHost::SuddenTerminationAllowed() const {
 // RenderViewHost, IPC message handlers:
 
 bool RenderViewHost::OnMessageReceived(const IPC::Message& msg) {
-  if (!BrowserMessageFilter::CheckCanDispatchOnUI(msg, this))
+#if defined(OS_WIN)
+  // On Windows there's a potential deadlock with sync messsages going in
+  // a circle from browser -> plugin -> renderer -> browser.
+  // On Linux we can avoid this by avoiding sync messages from browser->plugin.
+  // On Mac we avoid this by not supporting windowed plugins.
+  if (msg.is_sync() && !msg.is_caller_pumping_messages()) {
+    // NOTE: IF YOU HIT THIS ASSERT, THE SOLUTION IS ALMOST NEVER TO RUN A
+    // NESTED MESSAGE LOOP IN THE RENDERER!!!
+    // That introduces reentrancy which causes hard to track bugs.  You should
+    // find a way to either turn this into an asynchronous message, or one
+    // that can be answered on the IO thread.
+    NOTREACHED() << "Can't send sync messages to UI thread without pumping "
+        "messages in the renderer or else deadlocks can occur if the page "
+        "has windowed plugins! (message type " << msg.type() << ")";
+    IPC::Message* reply = IPC::SyncMessage::GenerateReply(&msg);
+    reply->set_reply_error();
+    Send(reply);
     return true;
+  }
+#endif
 
   {
     // delegate_->OnMessageReceived can end up deleting |this|, in which case