Index: chrome/browser/renderer_host/resource_message_filter.cc |
=================================================================== |
--- chrome/browser/renderer_host/resource_message_filter.cc (revision 25977) |
+++ chrome/browser/renderer_host/resource_message_filter.cc (working copy) |
@@ -334,7 +334,7 @@ |
#if defined(OS_WIN) |
IPC_MESSAGE_HANDLER(ViewHostMsg_DuplicateSection, OnDuplicateSection) |
#endif |
-#if defined(OS_LINUX) |
+#if defined(USE_X11) |
IPC_MESSAGE_HANDLER(ViewHostMsg_AllocateShareMemory, |
OnAllocateShareMemory) |
#endif |
@@ -620,9 +620,9 @@ |
ui_loop()->PostTask(FROM_HERE, new WriteClipboardTask(long_living_objects)); |
} |
-#if !defined(OS_LINUX) |
-// On non-Linux platforms, clipboard actions can be performed on the IO thread. |
-// On Linux, since the clipboard is linked with GTK, we either have to do this |
+#if !defined(USE_X11) |
+// On non-X/11 platforms, clipboard actions can be performed on the IO thread. |
+// On X/11, since the clipboard is linked with GTK, we either have to do this |
// with GTK on the UI thread, or with Xlib on the BACKGROUND_X11 thread. In an |
// ideal world, we would do the latter. However, for now we're going to |
// terminate these calls on the UI thread. This risks deadlock in the case of |
@@ -702,7 +702,7 @@ |
} |
#endif |
-#if defined(OS_LINUX) |
+#if defined(USE_X11) |
void ResourceMessageFilter::OnAllocateShareMemory( |
size_t buffer_size, |
base::SharedMemoryHandle* browser_handle) { |