focus issues breaking autopilot tests entering text

[Ken VanDine]

When running the autopilot tests for ubuntu-system-settings, at some point it fails to enter text using the OSK. It works fine for smaller subsets of the tests, but not a full run. It simply stops entering text with keyboard.type(). Once it gets in this state, it will continue to fail even for single tests until unity8 is restarted. During the test run, there is a unity8 crash file generated. I wasn't able to create a bug report for the problem directly from the OOPS on errors.ubuntu.com, you can find it at https://errors.ubuntu.com/oops/c4124284-1999-11e5-8fcb-fa163e75317b

My device:
current build number: 234
device name: mako
channel: ubuntu-touch/devel-proposed/ubuntu
last update: 2015-06-23 00:04:08
version version: 234
version ubuntu: 20150623
version device: 20150529.1
version custom: 20150623

@osomon has seen the same problem while running the webbrowser-app tests on krillin with vivid-proposed.

[Allan LeSage (allanlesage)]

Added Mirv as recent Qt landings may be implicated?

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Ken VanDine (ken-vandine)]

Link to a CI log:
https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/117/testReport/junit/ubuntu_system_settings.tests.test_cellular/DualSimCellularTestCase/test_change_sim1_name/

[Christopher Lee (veebers)]

It seems I was debugging something similar with rhuddie the other day (without solution). In case it's useful I'll mention it here:

What I observed was the test in question would stop then start the maliit-server, then the test immediately clicked on a text input and failed as the OSK never came up on screen within the time limit (presumably due to the process still starting up to the point it could accept the input etc.). At this point onwards any attempt to use the non-osk keyboard would fail. If we point a sleep between starting and trying to use the OSK everything worked fine.

Perhaps there is some interaction here which is stopping the text field to actually get focus? Or perhaps attempting to interact with the OSK before it's ready is confusing something?

As mentioned, I was unable to determine the actual issue, perhaps this information might help though.

[Olivier Tilloy (osomon)]

I am seeing the same issue intermittently when running the webbrowser_app test suite on devices (both in CI runs on mako and locally on my krillin). See e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2759/.
At some point during the test run, something happens and inputting text with the OSK doesn’t work any longer, thus causing all subsequent tests to fail.

[Daniel d'Andrada (dandrader)]

Ran "autopilot3 run ubuntu_system_settings" with Ubuntu 15.04 (r176) on mako

Got 38 test failures but unity8 didn't crash and I could still type normally on the virtual keyboard afterwards.

I was running a debug build of unity8 under gdb. With very nasty bugs this has an influence.

[Olivier Tilloy (osomon)]

This now seems to affect all automated CI runs for webbrowser-app merge requests on mako (vivid), thus preventing any automated validation. Can the importance be bumped to critical?

[Olivier Tilloy (osomon)]

Daniel: note that when autopilot tests start failing, manually typing with the OSK works (as you’ve observed), what doesn’t is autopilot’s write() method that simulates keyboard input.

[Daniel d'Andrada (dandrader)]

Which makes me wonder why was unity8 the first team summoned to investigate it.

[Olivier Tilloy (osomon)]

I guess because we initially thought the unity8 crash was causing the issue. It seems you’ve been able to observe the issue without a crash though, which would indicate that the issue might be somewhere else in the stack.

[Daniel d'Andrada (dandrader)]

I reboot the phone and run:
$ autopilot3 run ubuntu_system_settings.tests.test_search.SearchTestCases.test_search_filter_results

And it fails:
"""
testtools.matchers._impl.MismatchError: After 10.0 seconds test on TextField.text failed: 'Sound' != dbus.String('Som', variant_level=1)
"""

The test does "self._type_into_search_box('Sound')" but I see "Som" showing up in the text field. char by char. Smells like some lower level mess up.

On a second run nothing gets typed at all.

Note that autopilot's keyboard.type() function emulates a physical keyboard entering chars via evdev, which is a whole different code path from how the virtual keyboard feeds chars into the client app, which is done via D-Bus.

[Daniel d'Andrada (dandrader)]

But still, entering text via a physical keyboard should still work.

[Ken VanDine (ken-vandine)]

It seems be related to a test failure that puts the fake keyboard into a bad state. The only way to fix that state is by restarting unity8. I'm not sure what that has to do with unity8, but somehow restarting it clears it up. In the case of settings there was a real failure buried in the noise caused by the bad state.

[Daniel d'Andrada (dandrader)]

So the problem is that unity-system-compositor is dropping the uinput fake kbd events from autopilot, instead of forwarding them to unity8.

"""
[1435688811.380008] android-input: [InputDispatcher]Dropping event because there is no focused window or focused application.
""""

[Daniel d'Andrada (dandrader)]

Set the mir bug to "Critical" as that was the importance set on untiy8

[Launchpad Janitor (janitor)]

This bug was fixed in the package ubuntu-system-settings - 0.3+15.10.20150702.3-0ubuntu1

---------------
ubuntu-system-settings (0.3+15.10.20150702.3-0ubuntu1) wily; urgency=medium

  [ CI Train Bot ]
  * New rebuild forced.

  [ Ken VanDine ]
  * Test searching for WiFi instead of Sound, online-accounts now has a
    soundcloud account type (LP: #1468029)

  [ Matthew Paul Thomas ]
  * Changes "Install & Restart" to "Restart & Install" and "Not Now" to
    "Cancel". lp:1359344 (LP: #1359344)

  [ jonas-drange ]
  * implement CFB, CFNRy and CFNRc as well as autopilot tests (LP:
    #1463828)

 -- CI Train Bot <email address hidden> Thu, 02 Jul 2015 22:48:32 +0000

[Timo Jyrinki (timo-jyrinki)]

Just a brief thank you for an interesting bug report, I was on holidays so I didn't reply earlier. Digesting the messages, it sounds like nothing yet points to a Qt internal problem? One useful tidbit is that wily has Qt 5.4.2 while vivid has Qt 5.4.1, so it's useful to compare in case of problems.

[Robert Carr (robertcarr)]

I'm developing a theory related to mirscreencast stealing focus and triggering a bug in sessions without surfaces...it may be fixed in Mir 0.14 but it doesn't seem like I can test for a few more hours (so perhaps not until tomorrow)

[Robert Carr (robertcarr)]

Hi Everyone, just a quick update!

It seems that this bug has disappeared with the introduction of Mir 0.14...I suspect due to some reshuffling of USC window management logic.

Unfortunately a new issue has arisen in that Mir 0.14 repeats keys far too quickly causing autopilot tests to fail. I've prepared a fix here: https://code.launchpad.net/~mir-team/mir/fix-initial-key-repeat-timeout/+merge/264205 and we are discussing the best way to release it.

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:mir at revision None, scheduled for release in mir, milestone 0.15.0

[Daniel van Vugt (vanvugt)]

Please keep that tag. I use it for periodic quality analysis.