Mac: Remove a case where panels may become key when an autofill popup closes

chrome/browser/ui/cocoa/panels/panel_window_controller_cocoa.mm

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/ui/cocoa/panels/panel_window_controller_cocoa.h"
 
 #import <Cocoa/Cocoa.h>
 
 #include "base/auto_reset.h"
 #include "base/logging.h"
@@ skipping 77 matching lines @@
   BrowserCrApplication* app = base::mac::ObjCCast<BrowserCrApplication>(
       [BrowserCrApplication sharedApplication]);
 
   // A Panel window can become the key window only in limited scenarios.
   // This prevents the system from always preferring a Panel window due
   // to its higher priority NSWindowLevel when selecting a window to make key.
   return ([app isHandlingSendEvent]  && [[app currentEvent] window] == self) ||
       [controller activationRequestedByPanel] ||
       [app isCyclingWindows] ||
       [self isKeyWindow] ||
-      [app previousKeyWindow] == self ||

[Scott Hess - ex-Googler, 2016/01/12 22:29:54]

AFAICT, the only reason |previousKeyWindows_| in
chrome_browser_application_mac.mm exists is to support this check.  Removing all
of that makes me a little nervous (what if there are interesting non-obvious
side effects?), but not removing all of that also makes me nervous.

In the bug comment #3, it sounds like the sequence should be:
1) key window is new tab, previous is unknown.
2) key window is chat window, previous is #1's tab.
3.1) key window is #1's tab again, previous is #2's chat window.
3.2) key window is autocomplete popup, previous is #1's tab (the login page).

AFAICT, the problem at #4 is that when the key window is the autocomplete popup,
the previous key window is the chat window, instead of #1's tab (well, or window
thereof).  That would imply that the code to update the previousKeyWindows_
vector isn't firing for some reason.

OR, the problem at #4 is that the autocomplete popup doesn't become key window,
but dismissing it does cause the search for the previous key window.  In that
case, the current key window is still the tab's window, and the previous key
window is the chat window, and it should be re-selecting the current key window
somehow.

[OR this needs more thought, again.  It's hard to get back into the flow of this
kind of change, since it's complicated visible code interacting with complicated
invisible (and undocumented) code.]

       [[app windows] count] == static_cast<NSUInteger>([controller numPanels]);
 }
 
 - (void)performMiniaturize:(id)sender {
   [[self windowController] minimizeButtonClicked:0];
 }
 
 - (void)mouseMoved:(NSEvent*)event {
   // Cocoa does not support letting the application determine the edges that
   // can trigger the user resizing. To work around this, we track the mouse
@@ skipping 848 matching lines @@
       if (![window canBecomeKeyWindow])
         continue;
 
       [window makeKeyWindow];
     }
     return;
   }
 }
 
 @end