MacViews: Intercept events for Menus (after AppKit has interpreted keystrokes)

MacViews: Intercept events for Menus (after AppKit has interpreted keystrokes)

Currently keystrokes while a menu is open are sent to the window hosting
the menu, since it remains `key`. Concretely, 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.

BUG=403679

[tapted, 2014-12-19 00:22:22]

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

[tapted, 2014-12-19 00:31:10]

Hi Andre - I was hoping you could have an early look at Patchset 4. You did a
lot of the menu and textinput stuff, so might have some ideas around how this
idea will interact..

I'm not sure about the departure from intercepting events using a custom
dispatcher that other platforms do, but this seems like a simple approach that
might cover all the bases. (sky might have a different opinion too)

I still want to map some more action messages, and add a native test or two.

And while this gets all 25 Menu* interactive_ui_tests working for me locally,
when I run it on a trybot it's not happy, so I need to figure out what's going
on there.

Also tested with the combobox in views_examples_with_content_exe - seems like
this is on the right track. Thanks!

[Andre, 2014-12-19 06:41:57]

Looks good, I think this approach should work.
A bit unrelated, but I'm still unclear about how first responder setting will
work.
For example, when clicking in the omnibox, should firstResponder move from
RenderWidgetHostViewMac to BridgedContentView?

https://codereview.chromium.org/809773006/diff/60001/ui/views/cocoa/bridged_c...
File ui/views/cocoa/bridged_content_view.mm (right):

https://codereview.chromium.org/809773006/diff/60001/ui/views/cocoa/bridged_c...
ui/views/cocoa/bridged_content_view.mm:182: [self interpretKeyEvents:@[ theEvent
]];
How about when BridgedContentView is not first responder?
For example, in a browser window, RenderWidgetHostViewMac might be first
responder.
Does the key event get forwarded here?

[tapted, 2015-01-23 02:45:56]

Patchset #10 (id:180001) has been deleted

[tapted, 2015-01-28 09:36:18]

Patchset #13 (id:260001) has been deleted

[tapted, 2015-01-28 11:18:06]

https://codereview.chromium.org/809773006/diff/60001/ui/views/cocoa/bridged_c...
File ui/views/cocoa/bridged_content_view.mm (right):

https://codereview.chromium.org/809773006/diff/60001/ui/views/cocoa/bridged_c...
ui/views/cocoa/bridged_content_view.mm:182: [self interpretKeyEvents:@[ theEvent
]];
On 2014/12/19 06:41:57, Andre wrote:
> How about when BridgedContentView is not first responder?
> For example, in a browser window, RenderWidgetHostViewMac might be first
> responder.
> Does the key event get forwarded here?

So this was an excellent point :)

it crossed my mind, but I naively thought that it wouldn't matter. Thinking
went: ~"it won't come up since to show a drop-down menu in Views the
RenderWidgetHostViewMac wouldn't have focus anyway". But that's not the case. We
would still want the web content showing focus/firstResponder status, so can't
take it away.

I tried a *lot* of things and eventually got to something that seems to work
pretty nice with a combination of an override of -[NSWindow sendEvent] and an
override of -[NSView inputContext].

But then while adding tests it all got a bit unwieldy, so I've split this up
into 4 CLs:

http://crrev.com/856313003 Mac: Refine ui_controls_mac's SynthesizeKeyEvent()
[landed]
http://crrev.com/882053002 MacViews: Move some key-event utility functions out
of anon namespaces
http://crrev.com/879253002 MacViews: Convert Cocoa action messages into editing
comands for text fields
http://crrev.com/866983006 MacViews: Intercept events for Menus (after AppKit
has turned them into action messages).



the last one has the "interesting" stuff for the event interception (and
highlights the approach I eventually got to), but the textfields one should land
first since it's more mechanical - I'll send it out for your review now.