MacViews: Modify insertText handlers to correctly handle space key and simplify menu event dispatch.

ui/base/test/ui_controls_mac.mm

Index: ui/base/test/ui_controls_mac.mm
diff --git a/ui/base/test/ui_controls_mac.mm b/ui/base/test/ui_controls_mac.mm
index b7615b6c2fd78eab1ddbb87a351cf33f47c4efd1..1f46746c67699b4ad45e1a5df7a373670dc96d1e 100644
--- a/ui/base/test/ui_controls_mac.mm
+++ b/ui/base/test/ui_controls_mac.mm
@@ -14,25 +14,16 @@
 #include "ui/events/keycodes/keyboard_code_conversion_mac.h"
 #import "ui/events/test/cocoa_test_event_utils.h"
 
-// Implementation details: We use [NSApplication sendEvent:] instead
-// of [NSApplication postEvent:atStart:] so that the event gets sent
-// immediately.  This lets us run the post-event task right

[tapted, 2016/06/06 04:44:05]

So, sadly we will need to land the change that converts this from sendEvent to
postEvent separately -- there may be some subtle changes (e.g. maybe things
become flaky on some bots), and some other Cocoa folks should look at it too.

[karandeepb, 2016/06/06 11:21:09]

Done. See crrev.com/2035393002.

-// immediately as well.  Unfortunately I cannot subclass NSEvent (it's
-// probably a class cluster) to allow other easy answers.  For
-// example, if I could subclass NSEvent, I could run the Task in it's
-// dealloc routine (which necessarily happens after the event is
-// dispatched).  Unlike Linux, Mac does not have message loop
-// observer/notification.  Unlike windows, I cannot post non-events

[tapted, 2016/06/06 04:44:05]

Should we keep some of these notes?

[karandeepb, 2016/06/06 11:21:09]

These notes are explaining why [NSApp sendEvent] is being used. But since we are
removing the last usage of sendEvent from this file, these should probably be
removed.

-// into the event queue.  (I can post other kinds of tasks but can't
-// guarantee their order with regards to events).
-
-// But [NSApplication sendEvent:] causes a problem when sending mouse click
+// [NSApplication sendEvent:] causes a problem when sending mouse click
 // events. Because in order to handle mouse drag, when processing a mouse
 // click event, the application may want to retrieve the next event
 // synchronously by calling NSApplication's nextEventMatchingMask method.
 // In this case, [NSApplication sendEvent:] causes deadlock.
-// So we need to use [NSApplication postEvent:atStart:] for mouse click
-// events. In order to notify the caller correctly after all events has been
+// Also since events sent using [NSApp sendEvent] are not added to the event
+// queue but instead are invoked directly from the main event loop,
+// [NSApp currentEvent] does not report the correct event for it.
+// So we need to use [NSApplication postEvent:atStart:].
+// In order to notify the caller correctly after all events has been

[tapted, 2016/06/06 04:44:05]

has -> have

[karandeepb, 2016/06/06 11:21:09]

Done.

 // processed, we setup a task to watch for the event queue time to time and
 // notify the caller as soon as there is no event in the queue.
 //
@@ -211,14 +202,9 @@ bool SendKeyPressNotifyWhenDone(gfx::NativeWindow window,
   SynthesizeKeyEventsSequence(
       window, key, control, shift, alt, command, &events);
 
-  // TODO(suzhe): Using [NSApplication postEvent:atStart:] here causes
-  // BrowserKeyEventsTest.CommandKeyEvents to fail. See http://crbug.com/49270
-  // But using [NSApplication sendEvent:] should be safe for keyboard events,
-  // because until now, no code wants to retrieve the next event when handling
-  // a keyboard event.
   for (std::vector<NSEvent*>::iterator iter = events.begin();
        iter != events.end(); ++iter)
-    [[NSApplication sharedApplication] sendEvent:*iter];
+    [[NSApplication sharedApplication] postEvent:*iter atStart:NO];
 
   if (!task.is_null()) {
     base::MessageLoop::current()->PostTask(