MacViews: Implement capture using NSEvent local+global monitors

MacViews: Implement capture using NSEvent local+global monitors

This allows drag&drop to work, and Menus to dismiss themselves properly.

Adds a CocoaMouseCapture to encapsulate the logic to simulate
::SetCapture() from Windows APIs. "Cocoa" because it uses the cocoa APIs
on NSEvent rather than Quartz APIs from CoreGraphics to intercept mouse
events. (Quartz allows events sent to other applications to be
suppressed as well as monitored, but we don't want that).

Allows the WidgetCaptureTests in widget_interactive_test.cc to pass. One
test was failing because the widget could not activate, so the code in
native_widget_mac_interactive_uitest.mm that was setting the activation
policy is moved to views_test_helper_mac.mm.

BUG=403679
Committed: https://crrev.com/20cd5d3a1e1ff560fff0edfc736bc1ce6cd895a7
Cr-Commit-Position: refs/heads/master@{#308886}

[tapted, 2014-12-09 10:13:20]

Patchset #2 (id:20001) has been deleted

[tapted, 2014-12-09 10:13:32]

Patchset #1 (id:1) has been deleted

[tapted, 2014-12-12 06:52:15]

Patchset #5 (id:120001) has been deleted

[tapted, 2014-12-12 07:00:45]

tapted@chromium.org changed reviewers:
+ andresantoso@chromium.org

[tapted, 2014-12-12 07:03:32]

Hi Andre - could you take a first look?

That pressedMouseButtons change in event_generator_delegate_mac.mm change in
https://codereview.chromium.org/793003004/ turned out to be quite timely, since
I hit the same thing with these capture tests!

[Andre, 2014-12-12 22:57:38]

lgtm

https://codereview.chromium.org/789763002/diff/140001/ui/views/cocoa/cocoa_mo...
File ui/views/cocoa/cocoa_mouse_capture_unittest.mm (right):

https://codereview.chromium.org/789763002/diff/140001/ui/views/cocoa/cocoa_mo...
ui/views/cocoa/cocoa_mouse_capture_unittest.mm:17: int mouseDownCount_;
Objective-C style guide says that underscore should be in front, but ok for
existing projects to keep using underscore at the end. 
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Varia...
Chrome Mac is now 64-bits only (except for some bots that haven't been
updated), so we can soon start using modern ObjC features such as
auto-synthesis of ivars and accessors.
Putting underscores in front would make that transition easier, but at
the expense of inconsistency with the rest of the project.
Either way is OK with me, just wanted to bring it up.
See
http://useyourloaf.com/blog/2012/08/01/property-synthesis-with-xcode-4-dot-4....

https://codereview.chromium.org/789763002/diff/140001/ui/views/widget/widget_...
File ui/views/widget/widget_interactive_uitest.cc (right):

https://codereview.chromium.org/789763002/diff/140001/ui/views/widget/widget_...
ui/views/widget/widget_interactive_uitest.cc:1032: #endif  //
!defined(OS_CHROMEOS)
Update comment or delete.

[tapted, 2014-12-17 03:14:11]

Patchset #6 (id:160001) has been deleted

[tapted, 2014-12-17 03:20:51]

https://codereview.chromium.org/789763002/diff/140001/ui/views/cocoa/cocoa_mo...
File ui/views/cocoa/cocoa_mouse_capture_unittest.mm (right):

https://codereview.chromium.org/789763002/diff/140001/ui/views/cocoa/cocoa_mo...
ui/views/cocoa/cocoa_mouse_capture_unittest.mm:17: int mouseDownCount_;
On 2014/12/12 22:57:38, Andre wrote:
> Objective-C style guide says that underscore should be in front, but ok for
> existing projects to keep using underscore at the end. 
>
http://google-styleguide.googlecode.com/svn/trunk/objcguide.xml?showone=Varia...
> Chrome Mac is now 64-bits only (except for some bots that haven't been
> updated), so we can soon start using modern ObjC features such as
> auto-synthesis of ivars and accessors.
> Putting underscores in front would make that transition easier, but at
> the expense of inconsistency with the rest of the project.
> Either way is OK with me, just wanted to bring it up.
> See
>
http://useyourloaf.com/blog/2012/08/01/property-synthesis-with-xcode-4-dot-4....

Ooh - interesting. TBH, I think there is so much more C++ code in Chrome that
moving the underscore to the front will be a hard sell, even though they're in
camelCase as well. A leading underscore is still likely to make someone freak
out with a "that's reserved for the compiler/libraries" reaction (which used to
be true, but is mostly historical now - particularly for code only compiled for
Apple stuff - like that article points out)

https://codereview.chromium.org/789763002/diff/140001/ui/views/widget/widget_...
File ui/views/widget/widget_interactive_uitest.cc (right):

https://codereview.chromium.org/789763002/diff/140001/ui/views/widget/widget_...
ui/views/widget/widget_interactive_uitest.cc:1032: #endif  //
!defined(OS_CHROMEOS)
On 2014/12/12 22:57:38, Andre wrote:
> Update comment or delete.
> 

Done (changed this into a MAYBE_ test [neater, keeps compile regressions, can
still run with --gtest_also_run_disabled_tests, easier to audit, etc.])

[tapted, 2014-12-17 03:27:35]

tapted@chromium.org changed reviewers:
+ sadrul@chromium.org

[tapted, 2014-12-17 03:27:36]

+sadrul for OWNERS

also cc rsesek in case you want to jump in. I think you've done a lot of the
windows-that-dismiss-themselves on Cocoa, so might have some extra tidbits.

(note there was a CGEventTap version at http://crbug.com/377863002, but I think
this is friendlier, and allows behaviour more like native NSMenus)

[Robert Sesek, 2014-12-17 15:51:46]

rsesek@chromium.org changed reviewers:
+ rsesek@chromium.org

[Robert Sesek, 2014-12-17 15:51:46]

LGTM. Yes, the CGEvent taps are much lower level; NSEvent is certainly easier to
work with.

[sadrul, 2014-12-17 16:22:24]

lgtm

https://codereview.chromium.org/789763002/diff/200001/ui/views/views.gyp
File ui/views/views.gyp (right):

https://codereview.chromium.org/789763002/diff/200001/ui/views/views.gyp#newc...
ui/views/views.gyp:37: 'cocoa/bridged_native_widget.mm',
sort

[tapted, 2014-12-17 22:03:28]

Thanks all!

https://codereview.chromium.org/789763002/diff/200001/ui/views/views.gyp
File ui/views/views.gyp (right):

https://codereview.chromium.org/789763002/diff/200001/ui/views/views.gyp#newc...
ui/views/views.gyp:37: 'cocoa/bridged_native_widget.mm',
On 2014/12/17 16:22:24, sadrul wrote:
> sort

Done.

[tapted, 2014-12-17 22:03:38]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2014-12-17 22:03:52]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/789763002/210001

[commit-bot: I haz the power, 2014-12-18 00:02:31]

Committed patchset #8 (id:210001)

[commit-bot: I haz the power, 2014-12-18 00:03:25]

Patchset 8 (id:??) landed as
https://crrev.com/20cd5d3a1e1ff560fff0edfc736bc1ce6cd895a7
Cr-Commit-Position: refs/heads/master@{#308886}