GitLab

Keyboard events that are targeted first at the web contents area, but
are not handled by the web contents, are bounced back to the browser
via the in content::RenderWidgetHostImpl::OnKeyboardEventAck, where
they are forwarded to BrowserFrameMac::HandleKeyboardEvent to be
redispatched in the browser process.

This redispatch happens in the browser process even if the keyboard
event originated in the app shim process. The result is strange
behavior such as command-N re-focusing Chrome and creating a new
browser window.

Ensure that the redispatch happens in the originating process, by
having BrowserFrameMac::HandleKeyboardEvent delegate the redispatch
to its NativeWidgetMac base class, which will then forward the
event to the app shim process.

Two small wrinkles about this:
- The type used by BrowserFrameMac::HandleKeyboardEvent is
  inconveniently content::NativeWebKeyboardEvent, which cannot be
  accessed in views/
  - the only thing used in redispatch is |os_event|, which was
    reconstructed from a blink::WebKeyboardEvent
  - instead of passing the event over mojo, just pass the parts that
    are extracted by blink::WebKeyboardEvent
  - ideally we should switch to using a ui::KeyEvent, and just pass
    that directly (and add a function to reconstitute a NSEvent
    from a ui::KeyEvent).
- When redispatched in-process, we do want to accurately know the
  return value from the redispatch.
  - To get this accurately, we take a different path in-process
    versus out-of-process (because the mojo call has no return value).
  - Always report out-of-process events as handled, to arrest further
    processing in the browser.

Bug: 895169
Change-Id: I5fe1011374a4ca5050c7af70d6118286f7b46b34
Reviewed-on: https://chromium-review.googlesource.com/c/1292446Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#601743}