Temporary fix for the Cocoa-in-renderer problem.

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

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

4 files changed, 44 insertions, 8 deletions

diff --git a/chrome/app/app-Info.plist b/chrome/app/app-Info.plist
index 07046fd..dce119f 100644
--- a/chrome/app/app-Info.plist
+++ b/chrome/app/app-Info.plist
@@ -22,5 +22,7 @@
 	<string>MainMenu</string>
 	<key>NSPrincipalClass</key>
 	<string>NSApplication</string>
+	<key>LSUIElement</key>
+	<string>1</string>
 </dict>
 </plist>
diff --git a/chrome/browser/browser_main_mac.mm b/chrome/browser/browser_main_mac.mm
index 719ee96..f926244 100644
--- a/chrome/browser/browser_main_mac.mm
+++ b/chrome/browser/browser_main_mac.mm
@@ -12,7 +12,7 @@
 namespace Platform {
 
 // Perform and platform-specific work that needs to be done before the main
-// message loop is created and initialized. 
+// message loop is created and initialized.
 //
 // For Mac, this involves telling Cooca to finish its initalization, which we
 // want to do manually instead of calling NSApplicationMain(). The primary
@@ -24,13 +24,26 @@ namespace Platform {
 void WillInitializeMainMessageLoop(const CommandLine & command_line) {
   [NSApplication sharedApplication];
   [NSBundle loadNibNamed:@"MainMenu" owner:NSApp];
+
+  // TODO(port): Use of LSUIElement=1 is a temporary fix.  The right
+  // answer is to fix the renderer to not use Cocoa.
+  //
+  // Chromium.app currently as LSUIElement=1 in it's Info.plist.  This
+  // allows subprocesses (created with a relaunch of our binary) to
+  // create an NSApplication without showing up in the dock.
+  // Subprocesses (such as the renderer) need an NSApplication for
+  // Cocoa happiness However, for the browser itself, we DO want it in
+  // the dock.  These 3 lines make it happen.
+  ProcessSerialNumber psn;
+  GetCurrentProcess(&psn);
+  TransformProcessType(&psn,  kProcessTransformToForegroundApplication);
 }
 
 // Perform platform-specific work that needs to be done after the main event
 // loop has ended. We need to send the notifications that Cooca normally would
 // telling everyone the app is about to end.
 void WillTerminate() {
-  [[NSNotificationCenter defaultCenter] 
+  [[NSNotificationCenter defaultCenter]
       postNotificationName:NSApplicationWillTerminateNotification
                     object:NSApp];
 }
diff --git a/chrome/common/child_thread.cc b/chrome/common/child_thread.cc
index d1a9893..bad15a6 100644
--- a/chrome/common/child_thread.cc
+++ b/chrome/common/child_thread.cc
@@ -20,12 +20,8 @@ ChildThread::ChildThread(Thread::Options options)
       switches::kProcessChannelID);
 
   if (CommandLine::ForCurrentProcess()->HasSwitch(switches::kUserAgent)) {
-#if defined(OS_WIN)
-    // TODO(port): calling this connects an, otherwise disconnected, subgraph
-    // of symbols, causing huge numbers of linker errors.
     webkit_glue::SetUserAgent(WideToUTF8(
         CommandLine::ForCurrentProcess()->GetSwitchValue(switches::kUserAgent)));
-#endif
   }
 }
 
diff --git a/chrome/renderer/renderer_main_platform_delegate_mac.mm b/chrome/renderer/renderer_main_platform_delegate_mac.mm
index 388305d..e1a6d41 100644
--- a/chrome/renderer/renderer_main_platform_delegate_mac.mm
+++ b/chrome/renderer/renderer_main_platform_delegate_mac.mm
@@ -8,6 +8,7 @@
 
 #import <Foundation/Foundation.h>
 #import <ApplicationServices/ApplicationServices.h>
+#import <Cocoa/Cocoa.h>
 extern "C" {
 #include <sandbox.h>
 }
@@ -41,6 +42,30 @@ void RendererMainPlatformDelegate::PlatformInitialize() {
                                            kCGBitmapByteOrder32Host);
   CGColorSpaceRelease(rgb_colorspace);
   CGContextRelease(tmp);
+
+#if 0
+
+  // Note: by default, Cocoa is NOT thread safe.  Use of NSThreads
+  // tells Cocoa to be MT-aware and create and use locks.  The
+  // renderer process only uses Cocoa from the single renderer thread,
+  // so we don't need to tell Cocoa we are using threads (even though,
+  // oddly, we are using Cocoa from the non-main thread.)
+  // The current limit of renderer processes is 20.  Brett states that
+  // (despite comments to the contrary) when two tabs are using the
+  // same renderer, we do NOT create a 2nd renderer thread in that
+  // process.  Thus, we don't need to MT-aware Cocoa.
+  // (Code and comments left here in case that changes.)
+  if (![NSThread isMultiThreaded]) {
+    NSString *string = @"";
+    [NSThread detachNewThreadSelector:@selector(length)
+                             toTarget:string
+                           withObject:nil];
+  }
+#endif
+
+  // Initialize Cocoa.  Without this call, drawing of native UI
+  // elements (e.g. buttons) in WebKit will explode.
+  [NSApplication sharedApplication];
 }
 
 void RendererMainPlatformDelegate::PlatformUninitialize() {
@@ -64,7 +89,7 @@ bool RendererMainPlatformDelegate::EnableSandbox() {
   // For the renderer, we give it a custom sandbox to lock down as tight as
   // possible, but still be able to draw.  If we're not a renderer process, it
   // usually means we're a unittest, so we use a pure compute sandbox instead.
-  
+
   const char *sandbox_profile = kSBXProfilePureComputation;
   uint64_t sandbox_flags = SANDBOX_NAMED;
 
@@ -80,7 +105,7 @@ bool RendererMainPlatformDelegate::EnableSandbox() {
     sandbox_profile = [sandbox_profile_path fileSystemRepresentation];
     sandbox_flags = SANDBOX_NAMED_EXTERNAL;
   }
-  
+
   char* error_buff = NULL;
   int error = sandbox_init(sandbox_profile, sandbox_flags,
                            &error_buff);