Completes the GetWindowRect/GetRootWindowRect/GetScreenInfo changes I thought I had finished with...

content/browser/browser_message_filter.cc

 // 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.
 
 #include "content/browser/browser_message_filter.h"
 
 #include "base/logging.h"
 #include "base/process.h"
 #include "base/process_util.h"
 #include "content/browser/user_metrics.h"
@@ skipping 82 matching lines @@
   return rv;
 }
 
 void BrowserMessageFilter::BadMessageReceived() {
   base::KillProcess(peer_handle(), content::RESULT_CODE_KILLED_BAD_MESSAGE,
                     false);
 }
 
 bool BrowserMessageFilter::CheckCanDispatchOnUI(const IPC::Message& message,
                                                 IPC::Message::Sender* sender) {
-#if defined(OS_WIN)
+#if defined(OS_WIN) && !defined(USE_AURA)
   // 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;
 }