The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/a29c0349c07a9e3e0ad51e7813a62aa5fc068f80

commit a29c0349c07a9e3e0ad51e7813a62aa5fc068f80
Author: Dan Erat <derat@chromium.org>
Date: Tue Sep 25 04:08:31 2018

Revert "Enable tast.ui.VirtualKeyboardOmnibox."

This reverts commit 44f376e51e5df8f8a73e6251987888d875abdca5.

Reason for revert: failed in login_VMSanity on elm-paladin:
 https://crbug.com/888884 

Original change's description:
> Enable tast.ui.VirtualKeyboardOmnibox.
> 
> Make failures block the CQ. Test looks stable enough.
> 
> BUG=chromium:879073
> TEST=Linux
> 
> Change-Id: I5ca3e21771c5ce3afb5e00d0afe3f16a9cef6760
> Reviewed-on: https://chromium-review.googlesource.com/1235366
> Commit-Ready: Darren Shen <shend@chromium.org>
> Tested-by: Darren Shen <shend@chromium.org>
> Reviewed-by: Dan Erat <derat@chromium.org>

BUG=chromium:879073, chromium:888884 

Change-Id: I4f99b774881864abca267ede26d2e95311588897
Reviewed-on: https://chromium-review.googlesource.com/1242703
Reviewed-by: Darren Shen <shend@chromium.org>
Reviewed-by: Dan Erat <derat@chromium.org>
Tested-by: Dan Erat <derat@chromium.org>

[modify] https://crrev.com/a29c0349c07a9e3e0ad51e7813a62aa5fc068f80/src/chromiumos/tast/local/bundles/cros/ui/virtual_keyboard_omnibox.go

Thanks derat@ for the revert. Does `cdp.Runtime: Evaluate: context deadline exceeded` just mean that the test timed out?

Failing code is:

	// Click on the omnibox.
	if err := tconn.EvalPromise(ctx, `
new Promise((resolve, reject) => {
	chrome.automation.getDesktop(root => {
		root.addEventListener('loadComplete', () => {
			const omnibox = root.find({ attributes: { role: 'textField', inputType: 'url' }});
			if (omnibox) {
				omnibox.doDefault();
				resolve();
			} else {
				reject('Could not find the omnibox in accessibility tree');
			}
		});
	});
})
`, nil); err != nil {
		s.Fatal("Failed to click the omnibox: ", err)
	}

One possibility is that loadComplete event fired before event listener is added?

Hmm, that could be a possibility. The API documentation just says:

    Returns a tree with a placeholder root node; listen for the "loadComplete" event to get a notification that the tree has fully loaded (the previous root node reference will stop working at or before this point).

I'll have a look tomorrow.

I had a chat with the folks who built the API and yeah listening for 'loadComplete' multiple times could be problematic. I suspect what's happening is:

1. We call getDesktop in vkb.IsShown. The desktop root loads.
2. We call getDesktop again to click the omnibox. The desktop root is already loaded, so the event handler doesn't trigger.

Aside: But how did the test pass so many times :|

As a workaround, I could just use WaitForExpr and query for the presence of the omnibox repeatedly. I'll send over a patch for this.

A full proper solution might be something like:

    getDesktop(root => {
      if omnibox is present
        click it
      else
        chrome.automation.addTreeChangeObserver("allTreeChanges", function(change) {
          if omnibox was added
            click it
        });
    });

But seems a bit overkill.

Dan: Why did no other test besides login_VMSanity fail? Also, there doesn't seem to be anything board-specific about this failure?

#6: I think the test is just failing inconsistently. It looks like the same failure has occurred several times on -release builders outside of login_VMSanity: http://stainless/search?view=list&first_date=2018-09-20&last_date=2018-09-26&test=%5Etast%5C.ui%5C.VirtualKeyboardOmnibox%24&status=FAIL&exclude_cts=false&exclude_not_run=false&exclude_non_release=true&exclude_au=true&exclude_acts=true&exclude_retried=true&exclude_non_production=false

I agree that it's probably not board-specific.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/platform/tast-tests/+/d3e93dbe7d307dedb16f34f93d928621d21a400b

commit d3e93dbe7d307dedb16f34f93d928621d21a400b
Author: Darren Shen <shend@chromium.org>
Date: Tue Oct 02 16:17:27 2018

Make virtual keyboard tast tests less flaky.

Recently we tried to remove the "informational" attribute from
ui.VirtualKeyboardOmnibox, but it caused some flaky failures.
The source of the flakiness might be from our use of the automation
API: the 'loadComplete' event only fires once, but we listen for
it multiple times, so the other times may not fire.

To fix this, we just repeatedly poll whenever we are waiting for
an element to appear, using |setTimeout|.

We also considered a more "proper" solution of listening only
re-querying on changes to the tree, but A) this requires adding
a JavaScript helper function and B) there could be a lot of tree
changes which means the test could run quite slowly.

BUG= chromium:888884 ,chromium:879073
TEST=tested on eve

Change-Id: I0df98ad7ebd9d31d0089392e256951c77bc6cf39
Reviewed-on: https://chromium-review.googlesource.com/1249403
Commit-Ready: Darren Shen <shend@chromium.org>
Tested-by: Darren Shen <shend@chromium.org>
Reviewed-by: Shuhei Takahashi <nya@chromium.org>

[modify] https://crrev.com/d3e93dbe7d307dedb16f34f93d928621d21a400b/src/chromiumos/tast/local/bundles/cros/ui/vkb/vkb.go
[modify] https://crrev.com/d3e93dbe7d307dedb16f34f93d928621d21a400b/src/chromiumos/tast/local/bundles/cros/ui/virtual_keyboard_omnibox.go
[modify] https://crrev.com/d3e93dbe7d307dedb16f34f93d928621d21a400b/src/chromiumos/tast/local/bundles/cros/ui/virtual_keyboard_typing.go