Change all platforms except Windows to access the clipboard solely from the UI thread

content/browser/renderer_host/clipboard_message_filter.cc

Index: content/browser/renderer_host/clipboard_message_filter.cc
diff --git a/content/browser/renderer_host/clipboard_message_filter.cc b/content/browser/renderer_host/clipboard_message_filter.cc
index 1825b344dfbbb4e7178507c7c1722cd481f0e8e2..f96151f5f282b28aa38851343b5131354d9323e2 100644
--- a/content/browser/renderer_host/clipboard_message_filter.cc
+++ b/content/browser/renderer_host/clipboard_message_filter.cc
@@ -39,12 +39,23 @@ ClipboardMessageFilter::ClipboardMessageFilter() {
 
 void ClipboardMessageFilter::OverrideThreadForMessage(
     const IPC::Message& message, BrowserThread::ID* thread) {
+  // Clipboard writes should always occur on the UI thread due the restrictions
+  // of various platform APIs. In general, the clipboard is not
+  // thread-safe, so all clipboard calls should be serviced from the UI thread.
+  //
+  // Windows needs clipboard reads to be serviced from the IO thread because
+  // these are sync IPCs which can result in deadlocks with NPAPI plugins if
+  // serviced from the UI thread. Note that Windows clipboard calls ARE
+  // thread-safe so it is ok for reads and writes to be serviced from different
+  // threads.
+#if !defined(OS_WIN)
+  if (IPC_MESSAGE_CLASS(message) == ClipboardMsgStart)
+    *thread = BrowserThread::UI;

[dcheng, 2012/02/17 19:43:22]

Doesn't this change result in us posting a task from the UI thread to the UI
thread on non-Windows platforms? See lines 89-127. Should we change that to
avoid posting a task redundantly?

[raymes, 2012/02/17 23:14:03]

Sounds good, I was considering this but wasn't sure. Updated in the new patch
set.

+#endif
+
 #if defined(OS_WIN)
   if (message.type() == ClipboardHostMsg_ReadImage::ID)
     *thread = BrowserThread::FILE;
-#elif defined(USE_X11)
-  if (IPC_MESSAGE_CLASS(message) == ClipboardMsgStart)
-    *thread = BrowserThread::UI;
 #endif
 }