Allow permission bubbles to participate in key event dispatch as if they were a Browser.

ui/base/cocoa/command_dispatcher.mm

 // Copyright 2015 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.
 
 #import "ui/base/cocoa/command_dispatcher.h"
 
 #include "base/logging.h"
 #include "ui/base/cocoa/cocoa_base_utils.h"
+#import "ui/base/cocoa/user_interface_item_command_handler.h"
+
+// Expose -[NSWindow hasKeyAppearance], which determines whether the traffic
+// lights on the window are "lit". CommandDispatcher uses this property on a
+// parent window to decide whether keys and commands should bubble up.
+@interface NSWindow (PrivateAPI)
+- (BOOL)hasKeyAppearance;
+@end
+
+@interface CommandDispatcher ()
+// The parent to bubble events to, or nil.
+- (NSWindow<CommandDispatchingWindow>*)bubbleParent;
+@end
 
 namespace {
 
 // Duplicate the given key event, but changing the associated window.
 NSEvent* KeyEventForWindow(NSWindow* window, NSEvent* event) {
   NSEventType event_type = [event type];
 
   // Convert the event's location from the original window's coordinates into
   // our own.
   NSPoint location = [event locationInWindow];
@@ skipping 47 matching lines @@
   if ([delegate_ eventHandledByExtensionCommand:event
                                    isRedispatch:redispatchingEvent_]) {
     return YES;
   }
 
   if (redispatchingEvent_)
     return NO;
 
   // Give a CommandDispatcherTarget (e.g. a web site) a chance to handle the
   // event. If it doesn't want to handle it, it will call us back with
-  // -redispatchKeyEvent:.
-  NSResponder* r = [owner_ firstResponder];
-  if ([r conformsToProtocol:@protocol(CommandDispatcherTarget)])
-    return [r performKeyEquivalent:event];
+  // -redispatchKeyEvent:. Only allow this behavior when dispatching key events
+  // on the key window.
+  if ([owner_ isKeyWindow]) {
+    NSResponder* r = [owner_ firstResponder];
+    if ([r conformsToProtocol:@protocol(CommandDispatcherTarget)])
+      return [r performKeyEquivalent:event];
+  }
 
   if ([delegate_ prePerformKeyEquivalent:event window:owner_])
     return YES;
 
   if ([owner_ defaultPerformKeyEquivalent:event])
     return YES;
 
-  return [delegate_ postPerformKeyEquivalent:event window:owner_];
+  if ([delegate_ postPerformKeyEquivalent:event window:owner_])
+    return YES;
+
+  // Allow commands to "bubble up" to CommandDispatchers in parent windows, if
+  // they were not handled here.
+  return [[self bubbleParent] performKeyEquivalent:event];
+}
+
+- (BOOL)validateUserInterfaceItem:(id<NSValidatedUserInterfaceItem>)item
+                       forHandler:(id<UserInterfaceItemCommandHandler>)handler {
+  // Since this class implements these selectors, |super| will always say they
+  // are enabled. Only use [super] to validate other selectors. If there is no
+  // command handler, defer to AppController.
+  if ([item action] == @selector(commandDispatch:) ||
+      [item action] == @selector(commandDispatchUsingKeyModifiers:)) {
+    if (handler)

[Robert Sesek, 2017/02/01 14:27:20]

Why the discrepancy in handling the result of validateUserInterfaceItem:?

- handler gets to return the result
- appController only gets to if its YES
- owner only gets to if YES
- bubbleParent gets to return the result

[tapted, 2017/02/01 23:36:01]

The problem is that (unlike performKeyEquivalent) -commandDispatch: doesn't give
a way to say "yes I handled that" (I toyed with adding a BOOL return to do this,
but found that is probably unnecessary).

This means that once NSMenu decides that -commandDispatch: is the chosen action,
it will only go to a single target (i.e. the first in the chain that
respondsToSelector:). All CommandProcessingWindows respond to commandDispatch,
so the "bubble up" logic picks the "right" one by the presence of |handler| --
That is, dispatch: (below) can't later decide to skip [handler
dispatchCommand:..] based on whether [handler validate..] returned YES or NO
here.

[NSApp ..] is the same for both so there shouldn't be a targeting issue there by
falling through (and it's necessary to allow bubbling of commandDispatch:).

The weird case comes from bubbling of things validated by the *superclass* of
bubbleParent via line 128, below. This works for some things, since NSMenu does
its own bubbling until it finds a target that respondsToSelector:.

Investigating further, currently this means that items targeting NSWindow like
`Zoom` which are disabled on bubbles in Views (since the bubble is not
Zoomable), but not in Cocoa (because it uses the `sharedKeyState` private APIs)
will now be enabled on Views (they weren't previously), but will NSBeep if you
try to select it (since the bubble respondsToSelector: but doesn't wanna). I've
added a TODO. It's unclear from the Harmony modality spec what the right action
is (i.e. it currently says all shortcuts that "make sense" should work while a
bubble is active, but I'm not sure what's sensible when the target/action is
specifically to do with window manipulation).

+      return [handler validateUserInterfaceItem:item window:owner_];
+
+    id appController = [NSApp delegate];
+    DCHECK([appController
+        conformsToProtocol:@protocol(NSUserInterfaceValidations)]);
+    if ([appController validateUserInterfaceItem:item])
+      return YES;
+  }
+
+  if ([owner_ defaultValidateUserInterfaceItem:item])
+    return YES;
+
+  return [[self bubbleParent] validateUserInterfaceItem:item];
 }
 
 - (BOOL)redispatchKeyEvent:(NSEvent*)event {
   DCHECK(event);
   NSEventType eventType = [event type];
   if (eventType != NSKeyDown && eventType != NSKeyUp &&
       eventType != NSFlagsChanged) {
     NOTREACHED();
     return YES;  // Pretend it's been handled in an effort to limit damage.
   }
@@ skipping 23 matching lines @@
   if (redispatchingEvent_) {
     // If we get here, then the event was not handled by NSApplication.
     eventHandled_ = NO;
     // Return YES to stop native -sendEvent handling.
     return YES;
   }
 
   return NO;
 }
 
+- (void)dispatch:(id)sender
+      forHandler:(id<UserInterfaceItemCommandHandler>)handler {

[tapted, 2017/02/01 10:35:01]

I might be able to store this in the CommandDispatcher instead.. Although I feel
like there was a reason we didn't go that route in the first place :/. Something
to explore I guess.

+  if (handler)
+    [handler commandDispatch:sender window:owner_];
+  else
+    [[self bubbleParent] commandDispatch:sender];
+}
+
+- (void)dispatchUsingKeyModifiers:(id)sender
+                       forHandler:(id<UserInterfaceItemCommandHandler>)handler {
+  if (handler)
+    [handler commandDispatchUsingKeyModifiers:sender window:owner_];
+  else
+    [[self bubbleParent] commandDispatchUsingKeyModifiers:sender];
+}
+
+- (NSWindow<CommandDispatchingWindow>*)bubbleParent {
+  NSWindow* parent = [owner_ parentWindow];
+  if (parent && [parent hasKeyAppearance] &&
+      [parent conformsToProtocol:@protocol(CommandDispatchingWindow)])
+    return static_cast<NSWindow<CommandDispatchingWindow>*>(parent);
+  return nil;
+}
+
 @end