MacViews: Intercept events for Menus (after AppKit has turned them into action messages).

MacViews: Intercept events for Menus (after AppKit has turned them into action messages).

Currently keystrokes while a menu is open are sent to the window hosting
the menu, since it remains `key`. Menus are a different window, so this
causes all the Menu* interactive_ui_tests to fail since they simulate
pressing ESC to dismiss the menu in the tests.

Other platforms insert an event dispatcher into the message pump for the
nested run loop that shows a menu, and redirect KeyDown events to the
MenuController.

On Mac, events need to be mapped to "Action" messages by an NSResponder
to obey platform behaviour and user customizations (e.g. a "Home"
keypress should be interpreted as beginning of document, not beginning
of line).

The approach in this CL is to check in BridgedContentView, an
NSResponder, for an active menu that should be receiving events instead.
Action messages are mapped to the KeyCode that toolkit-views expects for
that action, and the MenuController is given an opportunity to swallow
the event or have it sent on to the key window.

Gets the following interactive_ui_tests passing:
MenuControllerMnemonicTest*{NoMatch,TitleMatch,MnemonicMatch}
MenuItemViewTestRemoveWithSubmenu{0,1}*
(and all Menu interactive UI tests pass after this).

BUG=403679
Committed: https://crrev.com/370605a7ffb0392e48729591dc8f6fca79cdc987
Cr-Commit-Position: refs/heads/master@{#314711}

[tapted, 2015-01-29 09:28:20]

Patchset #3 (id:40001) has been deleted

[tapted, 2015-02-04 10:39:09]

Patchset #4 (id:80001) has been deleted

[tapted, 2015-02-04 10:51:34]

Patchset #4 (id:100001) has been deleted

[tapted, 2015-02-04 10:59:04]

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

[tapted, 2015-02-04 11:55:48]

Hi Andre and sky - please take a look. Andre for general review/Mac, and sky for
your menu expertise.

Note this is a bit of a departure from the nested-message-loop approach used on
linux/win... but (with the current information I have) I think it's the right
fit for Mac. It means key events will get funnelled through the same points as
mouse events currently do with Mac's `SetCapture`, and it might avoid some
disruptions that might result while we run Cocoa UI side-by-side while stuff
migrates.

Thanks!

https://codereview.chromium.org/866983006/diff/120001/ui/views/controls/menu/...
File ui/views/controls/menu/menu_controller.cc (right):

https://codereview.chromium.org/866983006/diff/120001/ui/views/controls/menu/...
ui/views/controls/menu/menu_controller.cc:821: }
This function started life being refactored out of
ui/views/controls/menu/menu_event_dispatcher_linux.cc's DispatchEvent() (see,
e.g., patchset 2). In the end, it had a fatal flaw in
`ui::GetCharacterFromKeyCode(..)` which doesn't handle unicode characters
properly (it's a test function really...). Then, after passing in the `unichar`
from the NSEvent I kept finding ways to simplify it, but the core logic is the
same.

[sky, 2015-02-04 18:43:24]

LGTM

[Andre, 2015-02-04 19:26:52]

LGTM

[tapted, 2015-02-05 01:33:13]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-02-05 01:34:09]

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

[commit-bot: I haz the power, 2015-02-05 01:38:54]

Committed patchset #4 (id:120001)

[commit-bot: I haz the power, 2015-02-05 01:41:15]

Patchset 4 (id:??) landed as
https://crrev.com/370605a7ffb0392e48729591dc8f6fca79cdc987
Cr-Commit-Position: refs/heads/master@{#314711}