Revert 120593 - Ensure the previously active browser window gets the focus after a browser window i…

chrome/browser/ui/cocoa/browser_window_cocoa.mm

Index: chrome/browser/ui/cocoa/browser_window_cocoa.mm
===================================================================
--- chrome/browser/ui/cocoa/browser_window_cocoa.mm	(revision 126246)
+++ chrome/browser/ui/cocoa/browser_window_cocoa.mm	(working copy)
@@ -154,10 +154,20 @@
   // If there is an overlay window, we contain a tab being dragged between
   // windows. Don't hide the window as it makes the UI extra confused. We can
   // still close the window, as that will happen when the drag completes.
-  if ([controller_ overlayWindow])
+  if ([controller_ overlayWindow]) {
     [controller_ deferPerformClose];
-  else
+  } else {
+    // Make sure we hide the window immediately. Even though performClose:
+    // calls orderOut: eventually, it leaves the window on-screen long enough
+    // that we start to see tabs shutting down. http://crbug.com/23959
+    // TODO(viettrungluu): This is kind of bad, since |-performClose:| calls
+    // |-windowShouldClose:| (on its delegate, which is probably the
+    // controller) which may return |NO| causing the window to not be closed,
+    // thereby leaving a hidden window. In fact, our window-closing procedure
+    // involves a (indirect) recursion on |-performClose:|, which is also bad.
+    [window() orderOut:controller_];
     [window() performClose:controller_];
+  }
 }
 
 void BrowserWindowCocoa::Activate() {