New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 723901 link

Starred by 1 user
Status: Fixed
Owner:
changwan@chromium.org
Closed: May 2017
Cc:
█ aelias@chromium.org
tedc...@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug



Sign in to add a comment

UrlBarTest shouldn't use real input method

Project Member Reported by changwan@chromium.org, May 17 2017 
UrlBarTest activates real input method, and the keyboard behavior interferes with the logic that is being tested.

I noticed that Google Keyboard sometimes calls

beginBatchEdit()
...(getTextBeforeCursor()?)
endBatchEdit()

for no apparent reason in the middle of a test run. This confuses batchedit logic in UrlBar.java, flakes some test, therefore blocks further development such as  issue 722908 , so marking as P2.

Attaching screenrecord for record.

This may explain the gray marks on the following:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#showAllRuns=true&testType=chrome_public_test_apk&tests=urlbartest

I'm pretty sure that we will get more of these if we remove RetryOnFailure annotation.
Project Member

Comment 1 by bugdroid1@chromium.org, May 23 2017 

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

commit bae36d8062ad39d994cdf27a99418ec3fbe5aa13
Author: changwan <changwan@chromium.org>
Date: Tue May 23 02:00:38 2017

Prevent real IME from interfering with UrlBarTest

Android framework does not provide an easy way to remove keyboard app
from the testing (unless you use Robolectric).

So far we have been allowing the current keyboard app to interfere with
test and thus flaked test results. Especially, when you make selection
change, Google Latin Keyboard tries to look at the new status by running

beginBatchEdit() -> getTextBeforeCursor() -> endBatchEdit().

And this disrupted batch edit logic such as mInBatchEditMode.

With this change, onCreateInputConnection() will now return null, so
keyboard app cannot interact with the text. Also, dispatchKeyEvent
will ignore key events when it has to.

Note that the test can still interact with BaseInputConnection's method
and thus affects EditText's Editable through UrlBar#getInputConnection().

In doing so, I've guarded KeyUtils#dispatchKeyEventToView() to work with
UI thread.

BUG= 723901 

Review-Url: https://codereview.chromium.org/2894073002
Cr-Commit-Position: refs/heads/master@{#473782}

[modify] https://crrev.com/bae36d8062ad39d994cdf27a99418ec3fbe5aa13/chrome/android/java/src/org/chromium/chrome/browser/omnibox/AutocompleteEditText.java
[modify] https://crrev.com/bae36d8062ad39d994cdf27a99418ec3fbe5aa13/chrome/android/javatests/src/org/chromium/chrome/browser/omnibox/UrlBarTest.java
[modify] https://crrev.com/bae36d8062ad39d994cdf27a99418ec3fbe5aa13/content/public/test/android/javatests/src/org/chromium/content/browser/test/util/KeyUtils.java

Comment 2 by changwan@chromium.org, May 24 2017

Status: Fixed (was: Assigned)
Closing. Note that there are still occasional test failures regarding focus change and waitForFocusAndKeyboardActive(), but they are out of the scope of this bug.
►

Sign in to add a comment