ui/views/cocoa/native_widget_mac_nswindow.mm

   1 // Copyright 2014 The Chromium Authors. All rights reserved.
   2 // Use of this source code is governed by a BSD-style license that can be
   3 // found in the LICENSE file.
   4
   5 #import "ui/views/cocoa/native_widget_mac_nswindow.h"
   6
   7 #include "base/mac/foundation_util.h"
   8 #import "ui/views/cocoa/views_nswindow_delegate.h"
   9 #include "ui/views/controls/menu/menu_controller.h"
  10 #include "ui/views/widget/native_widget_mac.h"
  11
  12 @interface NativeWidgetMacNSWindow ()
  13 - (ViewsNSWindowDelegate*)viewsNSWindowDelegate;
  14 - (views::Widget*)viewsWidget;
  15 - (BOOL)hasViewsMenuActive;
  16 @end
  17
  18 @implementation NativeWidgetMacNSWindow
  19
  20 - (ViewsNSWindowDelegate*)viewsNSWindowDelegate {
  21   return base::mac::ObjCCastStrict<ViewsNSWindowDelegate>([self delegate]);
  22 }
  23
  24 - (views::Widget*)viewsWidget {
  25   return [[self viewsNSWindowDelegate] nativeWidgetMac]->GetWidget();
  26 }
  27
  28 - (BOOL)hasViewsMenuActive {
  29   views::MenuController* menuController =
  30       views::MenuController::GetActiveInstance();
  31   return menuController && menuController->owner() == [self viewsWidget];
  32 }
  33
  34 // Ignore [super canBecome{Key,Main}Window]. The default is NO for windows with
  35 // NSBorderlessWindowMask, which is not the desired behavior.
  36 // Note these can be called via -[NSWindow close] while the widget is being torn
  37 // down, so check for a delegate.
  38 - (BOOL)canBecomeKeyWindow {
  39   return [self delegate] && [self viewsWidget]->CanActivate();
  40 }
  41
  42 - (BOOL)canBecomeMainWindow {
  43   return [self delegate] && [self viewsWidget]->CanActivate();
  44 }
  45
  46 // Override sendEvent to allow key events to be forwarded to a toolkit-views
  47 // menu while it is active, and while still allowing any native subview to
  48 // retain firstResponder status.
  49 - (void)sendEvent:(NSEvent*)event {
  50   NSEventType type = [event type];
  51   if ((type != NSKeyDown && type != NSKeyUp) || ![self hasViewsMenuActive]) {
  52     [super sendEvent:event];
  53     return;
  54   }
  55
  56   // Send to the menu, after converting the event into an action message using
  57   // the content view.
  58   if (type == NSKeyDown)
  59     [[self contentView] keyDown:event];
  60   else
  61     [[self contentView] keyUp:event];
  62 }
  63
  64 // Override display, since this is the first opportunity Cocoa gives to detect
  65 // a visibility change in some cases. For example, restoring from the dock first
  66 // calls -[NSWindow display] before any NSWindowDelegate functions and before
  67 // ordering the window (and without actually calling -[NSWindow deminiaturize]).
  68 // By notifying the delegate that a display is about to occur, it can apply a
  69 // correct visibility state, before [super display] requests a draw of the
  70 // contentView. -[NSWindow isVisible] can still report NO at this point, so this
  71 // gives the delegate time to apply correct visibility before the draw occurs.
  72 - (void)display {
  73   [[self viewsNSWindowDelegate] onWindowWillDisplay];
  74   [super display];
  75 }
  76
  77 // Override window order functions to intercept other visibility changes. This
  78 // is needed in addition to the -[NSWindow display] override because Cocoa
  79 // hardly ever calls display, and reports -[NSWindow isVisible] incorrectly
  80 // when ordering in a window for the first time.
  81 - (void)orderWindow:(NSWindowOrderingMode)orderingMode
  82          relativeTo:(NSInteger)otherWindowNumber {
  83   [[self viewsNSWindowDelegate] onWindowOrderWillChange:orderingMode];
  84   [super orderWindow:orderingMode relativeTo:otherWindowNumber];
  85   [[self viewsNSWindowDelegate] onWindowOrderChanged:nil];
  86 }
  87
  88 // NSResponder implementation.
  89
  90 - (void)cursorUpdate:(NSEvent*)theEvent {
  91   // The cursor provided by the delegate should only be applied within the
  92   // content area. This is because we rely on the contentView to track the
  93   // mouse cursor and forward cursorUpdate: messages up the responder chain.
  94   // The cursorUpdate: isn't handled in BridgedContentView because views-style
  95   // SetCapture() conflicts with the way tracking events are processed for
  96   // the view during a drag. Since the NSWindow is still in the responder chain
  97   // overriding cursorUpdate: here handles both cases.
  98   if (!NSPointInRect([theEvent locationInWindow], [[self contentView] frame])) {
  99     [super cursorUpdate:theEvent];
 100     return;
 101   }
 102
 103   NSCursor* cursor = [[self viewsNSWindowDelegate] cursor];
 104   if (cursor)
 105     [cursor set];
 106   else
 107     [super cursorUpdate:theEvent];
 108 }
 109
 110 @end