GitLab

Tracking areas in Cocoa are a horrible mess. 10.5 semi-deprecated
NSWindow cursorRects, and introduced [NSResponder cursorUpdate:]. Both
are supported and they react with each other in strange ways.
Intercepting events for toolkit-views SetCapture seems to further
complicate things.

After numerous dead-ends, this CL implements SetCursor() by overriding
cursorUpdate: on NativeWidgetMac's NSWindow override. This works because
cursorUpdate: messages are forwarded along the responder chain (starting
from varied and somewhat unpredictable starting points), and usually end
up at the NSWindow.

Rather than adding more NSTrackingArea cruft, the one in
BridgedContentView is updated to handle cursor updates. This ensures the
cursor is reset to "normal" whenever it leaves the content area.

Installing a global event monitor also resets the mouse cursor to an
arrow. I tried tracing this with NSObjCMessageLoggingEnabled, but the
reset isn't done with Objective-C. To fix, "remind" AppKit what the
cursor should be after setting capture.

See code comments for all the other traps.

Testing tracking rectangles with simulated events is pretty much a lost
cause, but NativeWidgetMacTest.SetCursor() is added which gets some
coverage by sending an event directly to [NSWindow cursorUpdate:], and
using the ui::test::EventGenerator to forward events to toolkit-views to
actually request new cursors to set.

BUG=454698

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

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