Mac: Refine ui_controls_mac's SynthesizeKeyEvent()

Mac: Refine ui_controls_mac's SynthesizeKeyEvent()

In preparation for moving SynthesizeKeyEvent to cocoa_test_event_utils,
this refines the behavior of SynthesizeKeyEvent to more closely match
actual events. There were two bugs:

The unichar character being set on a simulated "Delete" key was actually
the unichar that Mac uses for "Backspace" (0x7f). Cocoa actually uses
0xf728 for the delete key (NSDeleteFunctionKey). Note "Backspace" stays
sending 0x8 (Ctrl+H) rather than being updated to 0x7f (ASCII DEL).
Either seems to work for Backspace (which meant simulated Deletes were
becoming deleteBackward action messages rather than deleteForward).

Also, SynthesizeKeyEvent is updated to closely follow the behavior on
Mac wrt Command/Shift modifiers. The bug here was that when *just*
Shift+letter is pressed, characters and charactersIgnoringModifiers
should *both* be uppercase. (r311815 swapped them for Ctrl, but didn't
try to fix Shift).

These changes are needed for comprehensive testing of views::TextField
on Mac. Specifically, to get TextfieldTest.ControlAndSelectTest and
TextfieldTest.ControlAndSelectTest passing with simulated NSEvents.

BUG=378134
Committed: https://crrev.com/c3217c83c5638ee9f4669628003b68df6694a02f
Cr-Commit-Position: refs/heads/master@{#313441}

[tapted, 2015-01-27 06:59:43]

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

[tapted, 2015-01-27 07:43:33]

Hi Nico - please take a look.

I also want to move SynthesizeKeyEvent() out of an anonymous namespace (probably
to cocoa_test_event_utils since it's not interactive-only), but wanted to land
these fixes first.

Additional context for these changes is in crrev/809773006

Thanks!

[Nico, 2015-01-27 18:55:15]

lgtm given that backspace on web contents still goes back (no idea if that goes
through that code path).

https://codereview.chromium.org/809773006/ looks like views-on-mac is very
similar to the original chrome/mac bring-up. I'm still very unconvinced of us
being in a better place with mac/views.

[tapted, 2015-01-28 00:56:33]

On 2015/01/27 18:55:15, Nico wrote:
> lgtm given that backspace on web contents still goes back (no idea if that
goes
> through that code path).

Double-checked to be sure - all good. Also it's a good case-study for
views-on-mac..

MacKeyCodeForWindowsKeyCode and friends actually started life only to support
tests (a looong time ago -- 2010 -- in http://crrev.com/53840 ). But
keyboard_code_conversion_mac.h was put in base/ not base/test/ . So it's since
been used by the extension system to allow it to describe global shortcuts in a
cross-platform way. So I checked those with a test extension --
http://pastebin.com/VUUDNZ3e -- just to be sure, and Cmd+Delete is still
captured as expected.

backspace-to-go-back is handled by the NSWindow subclass,
ChromeEventProcessingWindow, which sticks with Mac keycodes and a table provided
by global_keyboard_shortcuts_mac.mm's GetBrowserKeyboardShortcutTable which is
keyed on the vkey for things like delete (rather than the unichar).

> https://codereview.chromium.org/809773006/ looks like views-on-mac is very
> similar to the original chrome/mac bring-up. I'm still very unconvinced of us
> being in a better place with mac/views.

Don't worry - I am suitably daunted by the task :). It's still being treated as
an experiment. The bar is set high and "This sucks and is unsalvageable. We need
to invest in more Cocoa devs." would be a valid result of the experiment
(although disappointing for some).

[tapted, 2015-01-28 01:26:07]

The CQ bit was checked by tapted@chromium.org

[commit-bot: I haz the power, 2015-01-28 01:27:38]

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

[commit-bot: I haz the power, 2015-01-28 04:20:57]

Committed patchset #1 (id:1)

[commit-bot: I haz the power, 2015-01-28 04:22:51]

Patchset 1 (id:??) landed as
https://crrev.com/c3217c83c5638ee9f4669628003b68df6694a02f
Cr-Commit-Position: refs/heads/master@{#313441}