MacViews: Implement NativeWidgetMac::SetCursor()
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}
Showing
Please register or sign in to comment