Reassigning to rlanday@

I spent some time looking into this because it seems that ImeTest flakiness is preventing me from landing https://chromium-review.googlesource.com/c/chromium/src/+/740373.


I'm unable to reproduce the exact error message. My best guess for what's going on is that there's a race condition when we call:

DOMUtils.clickNode(mContentViewCore, "input_text");

On every frame, RenderWidget::WillBeginCompositorFrame() calls UpdateTextInputState(), which ends up calling InputMethodController::TextInputInfo(). There are a couple of conditions (!InputMethodController::IsAvailable(), !GetFrame().Selection().IsAvailable()), !RootEditableElementOfSelection(GetFrame().Selection()) where it seems like InputMethodController::TextInputInfo() returns an uninitialized struct, which might explain why the input type history looks weird. But again, I haven't been able to repro the exact behavior.

My explanation in Comment 2 is incorrect. 

RenderWidget::UpdateTextInputStateInternal() always gets the input type (which is ending up as an unexpected value in input type history) by calling InputMethodController::TextInputType() (unless there's a focused Pepper plugin, in which case RenderWidget::GetTextInputType() instead calls calls PepperPluginInstanceImpl::text_input_type()...but I don't think we have Pepper plugins when we run content tests?) Input type 4 corresponds to an email input, but it looks like InputMethodController::TextInputType() doesn't ever return kWebTextInputTypeEmail unless we actually have a focused email input. The page we load in ImeActivityTestRule, content/test/data/android/input/input_forms.html, doesn't have any email inputs, so I'm confused as to how one could become focused.

This is extremely difficult to debug without being able to see a screenshot and/or video of the test run. From the failure stack trace, it seems we have a class called ScreenshotOnFailureStatement that's supposed to take screenshots of test failures, but I can't figure out any way to download them from a try bot. Diagnosing flaky tests would be much easier if we could actually see what was happened when the test was run.

Ah, we do have screenshots if you click the result_details link on the try bot page. Unfortunately, they're not very helpful in this case.

I was misreading the input type history "14" as "fourteen" (i.e. a text area"), when really it means "1" "4" (i.e., the <input> element that's supposed to be focused gets focused, and then the <textarea> below it gets focused somehow).

Unfortunately I'm about out of ideas at the moment for how the <textarea> could end up getting focused, so I'm currently unable to resolve this flakiness.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/201f97c55a68f292c852a1dea3d19badc9c20320

commit 201f97c55a68f292c852a1dea3d19badc9c20320
Author: Ryan Landay <rlanday@chromium.org>
Date: Thu Nov 16 19:09:41 2017

Avoid scrolling in ImeTest to attempt to reduce flakiness

There are two problems with ImeTest that seem to be caused by scrolling (caused
by calling methods in DOMUtils, such as clickNode(), on various elements):

- Various test cases in ImeTest are intermittently failing in startup
  ( crbug.com/781174 ). I am unable to reproduce the problem or determine what's
  happening. Test output and screenshots taken upon failure seem to indicate
  that focus is somehow getting moved to the <textarea> element in the HTML file
  immediately after the first <input> element, instead of remaining on the
  <input>. I am hopeful that avoiding scrolling resolves this problem. At the
  very least, it will rule out a potential cause of the issue.

- In https://chromium-review.googlesource.com/c/chromium/src/+/740373, I
  attempted to land a change to the HTML file used by ImeTest to support a few
  new tests. The change made the webpage longer so more scrolling happens. In
  particular, a test failure results because single taps on two different
  elements are getting counted as a double tap, because scrolling is bringing
  the second element to the location of the first element (so the taps are now
  in the same location on screen, whereas before they were in different
  locations, and hence the taps weren't eligible to be interpreted as a
  double-tap.

  This issue *does* reproduce locally, and I have confirmed that avoiding
  scrolling fixes the issue.

This CL avoids scrolling in ImeTest by making the whole webpage fit on-screen.

Moving the elements closer together seems to make a click in
testKeyboardAppFinishesCompositionOnUnexpectedSelectionChange() get counted as a
double-click in some test runs (I had to compile a release build to test this),
so I'm also adding a call to Thread.sleep() in that test to avoid this problem.

Bug:  781174 
Change-Id: I4982be105846b954e7495fee682fcfe988dd2155
Reviewed-on: https://chromium-review.googlesource.com/773105
Reviewed-by: Changwan Ryu <changwan@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517142}
[modify] https://crrev.com/201f97c55a68f292c852a1dea3d19badc9c20320/content/public/android/javatests/src/org/chromium/content/browser/input/ImeTest.java
[modify] https://crrev.com/201f97c55a68f292c852a1dea3d19badc9c20320/content/test/data/android/input/input_forms.html

I think this is fixed now.