MacViews: "Implement" NativeViewHostMac::GetCursor(). The implementation is a comment.

The NOTIMPLEMENTED() in NativeViewHostMac::GetCursor(..) generates a lot
of spam. After some investigation, it doesn't need an implementation.

NativeViewHost::GetCursor() appeared in r256934 for Aura, but Mac
(without Aura) doesn't need it. Add a comment explaining the situation.

(See http://crrev.com/1504713009 for a possible implemenatation. It
makes tests happy, but doesn't actually achieve any change in
behaviour.)

BUG=565984

Review URL: https://codereview.chromium.org/1533783002

Cr-Commit-Position: refs/heads/master@{#366036}

1 files changed, 10 insertions, 1 deletions

diff --git a/ui/views/controls/native/native_view_host_mac.mm b/ui/views/controls/native/native_view_host_mac.mm
index 2ef7874..da057fa 100644
--- a/ui/views/controls/native/native_view_host_mac.mm
+++ b/ui/views/controls/native/native_view_host_mac.mm
@@ -136,7 +136,16 @@ gfx::NativeViewAccessible NativeViewHostMac::GetNativeViewAccessible() {
 }
 
 gfx::NativeCursor NativeViewHostMac::GetCursor(int x, int y) {
-  NOTIMPLEMENTED();
+  // Intentionally not implemented: Not required on non-aura Mac because OSX
+  // will query the native view for the cursor directly. For NativeViewHostMac
+  // in practice, OSX will retrieve the cursor that was last set by
+  // -[RenderWidgetHostViewCocoa updateCursor:] whenever the pointer is over the
+  // hosted view. With some plumbing, NativeViewHostMac could return that same
+  // cursor here, but it doesn't achieve anything. The implications of returning
+  // null simply mean that the "fallback" cursor on the window itself will be
+  // cleared (see -[NativeWidgetMacNSWindow cursorUpdate:]). However, while the
+  // pointer is over a RenderWidgetHostViewCocoa, OSX won't ask for the fallback
+  // cursor.
   return gfx::kNullCursor;
 }