Ensure the previously active browser window gets the focus after a browser window is closed on OSX.

chrome/browser/ui/cocoa/browser_window_cocoa.mm

Index: chrome/browser/ui/cocoa/browser_window_cocoa.mm
diff --git a/chrome/browser/ui/cocoa/browser_window_cocoa.mm b/chrome/browser/ui/cocoa/browser_window_cocoa.mm
index e2e94924b9edf59685ca9f3a158e889617497da1..89e6d63f0ae0aa972c6ac7ee5ba6032f9289a2af 100644
--- a/chrome/browser/ui/cocoa/browser_window_cocoa.mm
+++ b/chrome/browser/ui/cocoa/browser_window_cocoa.mm
@@ -153,20 +153,10 @@ void BrowserWindowCocoa::Close() {
   // 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 {
-    // 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_];
+  else
     [window() performClose:controller_];
-  }
 }
 
 void BrowserWindowCocoa::Activate() {