Added accurate TouchToMouseMode testing to SplitTap

chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc

Index: chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc
diff --git a/chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc b/chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc
index 43ef9138f037c1cfb05a14ddd36db9d836f23ff6..26a18b8294e17a15d0f928ae4d4bf79fcea750ce 100644
--- a/chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc
+++ b/chrome/browser/chromeos/accessibility/touch_exploration_controller_browsertest.cc
@@ -84,4 +84,39 @@ IN_PROC_BROWSER_TEST_F(TouchExplorationTest, ToggleOnOff) {
   root_window->RemovePreTargetHandler(event_handler.get());
 }
 
+// This test makes sure that after the user clicks with split tap,

[mfomitchev, 2014/06/27 19:15:46]

One more thing: I've just realized that a change I've landed today will
interfere with this test: https://codereview.chromium.org/330113002/

You'll need to rebase and WaitForResizeComplete() just like the other test does
now (see the diff on touch_exploration_controller_browsertest.cc in the review).

[evy, 2014/06/30 23:28:46]

Done.

+// they continue to touch exploration mode if the original touch exploration
+// finger is still on the screen.
+IN_PROC_BROWSER_TEST_F(TouchExplorationTest, SplitTapExplore) {

[mfomitchev, 2014/06/27 16:36:05]

Can you please add validation for the cursor client's state here? Eg:
1. Do a mouse move in the very beginning of the test, before the press. Check
that mouse events are enabled and the cursor is visible
2. Check that mouse events are enabled and the cursor is hidden after the first
press
3. Same after the first move
4. Check that mouse events are disabled and cursor is hidden after the second
press.
5. Check that mouse events are enabled and the cursor is hidden after the
release.

[evy, 2014/06/27 18:03:00]

Done. Though it turns out that mouse events aren't enabled after the first
press. Does that sound right to you?

[mfomitchev, 2014/06/27 19:15:46]

Right, that actually makes sense because the controller waits 300?ms before
moving to the touch exploration mode. So they should be enabled after press, but
get disabled after the move. If you are feeling ambitious, you can add a test
(at the end of this one) where you press, advance the clock by 500ms, and then
confirm the cursor is hidden.

[evy, 2014/06/30 23:28:46]

Working on it. Turns out this is more complicated than I thought.

+  aura::Window* root_window = ash::Shell::GetInstance()->GetPrimaryRootWindow();
+  scoped_ptr<ui::test::TestEventHandler>
+      event_handler(new ui::test::TestEventHandler());
+  root_window->AddPreTargetHandler(event_handler.get());
+  SwitchTouchExplorationMode(true);
+  aura::test::EventGenerator generator(root_window);
+
+  generator.set_current_location(gfx::Point(100, 200));
+  generator.PressTouchId(1);
+  // Initiate touch explore by moving out of the slop.
+  generator.MoveTouchId(gfx::Point(109, 209), 1);

[tdanderson, 2014/06/27 17:01:07]

Add EXPECT_EQ(1, event_handler->num_touch_events());

[evy, 2014/06/27 18:03:00]

There actually aren't any touch events passed through here, it's the same thing
as a mouse move.

+  event_handler->Reset();
+
+  // Press and release with a second finger for split tap. This should send
+  // touch press and release events which should send a click press and release.

[tdanderson, 2014/06/27 17:01:07]

For documentation's sake, it would be good to mention that the tap/click goes to
the location of the first finger. (Is that already tested somewhere?)

[evy, 2014/06/27 18:03:00]

Yup! This is tested in the SplitTap unit test. Should I check it here too?

+  generator.set_current_location(gfx::Point(102, 202));
+  generator.PressTouchId(2);
+  generator.ReleaseTouchId(2);
+  EXPECT_EQ(2, event_handler->num_touch_events());
+  event_handler->Reset();
+
+  // Continuing to move the touch exploration finger should send more mouse
+  // events.
+  generator.MoveTouchId(gfx::Point(509, 609), 1);
+  EXPECT_GT(event_handler->num_mouse_events(), 0);

[tdanderson, 2014/06/27 17:01:07]

It's better to use EXPECT_EQ if you know how many mouse events you're expecting.

[evy, 2014/06/27 18:03:00]

I noticed a comment above in another test:
// Number of mouse events may be greater than 1 because of ET_MOUSE_ENTERED.
Does that apply here?

note: this line has now been removed (from Hangouts discussion).

+  EXPECT_EQ(0, event_handler->num_touch_events());
+
+  SwitchTouchExplorationMode(false);
+  root_window->RemovePreTargetHandler(event_handler.get());
+}
+
 }  // namespace ui