Commit 201f97c5 authored by Ryan Landay's avatar Ryan Landay Committed by Commit Bot

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/773105Reviewed-by: default avatarChangwan Ryu <changwan@chromium.org>
Commit-Queue: Ryan Landay <rlanday@chromium.org>
Cr-Commit-Position: refs/heads/master@{#517142}
parent ab0c382d
......@@ -17,6 +17,7 @@ import android.text.Spanned;
import android.text.style.BackgroundColorSpan;
import android.text.style.UnderlineSpan;
import android.view.KeyEvent;
import android.view.ViewConfiguration;
import android.view.inputmethod.BaseInputConnection;
import android.view.inputmethod.EditorInfo;
......@@ -181,6 +182,9 @@ public class ImeTest {
mRule.waitAndVerifyUpdateSelection(2, 3, 3, 2, 3);
// Unexpected selection change occurs, e.g., the user clicks on an area.
// There was already one click during test setup; we have to wait out the double-tap
// timeout or the test will be flaky.
Thread.sleep(ViewConfiguration.getDoubleTapTimeout());
DOMUtils.clickNode(mRule.getContentViewCore(), "textarea2");
mRule.waitAndVerifyUpdateSelection(3, 5, 5, 2, 3);
// Keyboard app finishes composition. We emulate this in TestInputMethodManagerWrapper.
......
<!DOCTYPE html>
<!-- Note: if this page gets long (or wide) enough that it can't fit entirely on
the phone's display without scrolling, the test will start being flaky and
it will be very difficult to debug :(. -->
<html>
<head>
<meta name="viewport" content="width=device-width">
......@@ -6,26 +9,19 @@
<body>
<form action="about:blank">
<input id="input_text" type="text" size="10">
<br>
</form>
<form>
<br>
<textarea id="textarea" rows="4" cols="20"></textarea>
<br>
<textarea id="textarea2" rows="4" cols="20" autocomplete="off"></textarea>
<br>
<input id="input_number1" type="number"><br>
<input id="input_number2" type="number"><br>
<br>
<span id="plain_text">This is Plain Text One</span><br>
<br>
<textarea id="textarea" rows="2" cols="10"></textarea>
<textarea id="textarea2" rows="2" cols="10" autocomplete="off"></textarea>
<input id="input_number1" type="number">
<input id="input_number2" type="number"><br><br>
<!-- We need extra space around the plain text since otherwise taps on it
would get snapped to the surrounding <input> elements. -->
<span id="plain_text">This is Plain Text One</span><br><br>
<div id="contenteditable1" contenteditable>contenteditable1</div>
<br>
<input id="search1" type="search" size="10" size="10">
<br>
<input id="input_text1" type="text" size="10" size="10"><br>
<input id="input_radio" type="radio" style="width:50px;height:50px"><br>
<br>
</form>
<!-- We may trigger different sets of events for CONTENTEDITABLE and INPUT / TEXTAREA -->
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment