[Mac] A more robust way to ensure panels avoid key status on window close

chrome/browser/chrome_browser_application_mac.mm

Index: chrome/browser/chrome_browser_application_mac.mm
diff --git a/chrome/browser/chrome_browser_application_mac.mm b/chrome/browser/chrome_browser_application_mac.mm
index 1203c38b04fbcb4581f9a002f9fa6684cfb0899f..e648774a16a5bc68567109486ab69b097578272b 100644
--- a/chrome/browser/chrome_browser_application_mac.mm
+++ b/chrome/browser/chrome_browser_application_mac.mm
@@ -651,27 +651,13 @@ void SwizzleInit() {
 }
 
 - (id)_removeWindow:(NSWindow*)window {
+  // Note _removeWindow is called from -[NSWindow dealloc], which can happen at
+  // unpredictable times due to reference counting. Just update state.
   {
     base::AutoLock lock(previousKeyWindowsLock_);
     [self removePreviousKeyWindow:window];
   }
-  id result = [super _removeWindow:window];
-
-  // Ensure app has a key window after a window is removed.
-  // OS wants to make a panel browser window key after closing an app window
-  // because panels use a higher priority window level, but panel windows may
-  // refuse to become key, leaving the app with no key window. The OS does
-  // not seem to consider other windows after the first window chosen refuses
-  // to become key. Force consideration of other windows here.
-  if ([self isActive] && [self keyWindow] == nil) {
-    NSWindow* key =
-        [self makeWindowsPerform:@selector(canBecomeKeyWindow) inOrder:YES];
-    [key makeKeyWindow];
-  }
-
-  // Return result from the super class. It appears to be the app that
-  // owns the removed window (determined via experimentation).
-  return result;
+  return [super _removeWindow:window];
 }
 
 - (id)_setKeyWindow:(NSWindow*)window {