OSK does not appear during autopilot tests

[Richard Huddie]

The OSK has stopped appearing on screen during autopilot tests:

Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/ubuntu_keyboard/tests/test_keyboard.py", line 182, in test_keyboard_is_available
    self.assertThat(keyboard.is_available, Eventually(Equals(True)))
  File "/usr/lib/python3/dist-packages/testtools/testcase.py", line 423, in assertThat
    raise mismatch_error
testtools.matchers._impl.MismatchError: After 10.0 seconds test failed: True != False

This is easily reproducible by running ubuntu_keyboard.tests.test_keyboard.UbuntuKeyboardTestsAccess.test_keyboard_is_available

The same error is also seen in dashboard results:

http://rtm-dashboard.ci.ubuntu.com/smokeng/wily/touch/arale/58:20150714:20150709-8965e37/725/ubuntu_keyboard/

There was a recent submission to ubuntu-ui-toolkit which enabled using the osk for textfield.write(), so this error is also being seen by some app project tests.

[Ken VanDine (ken-vandine)]

We're seeing this in ubuntu-system-settings as well, with this exception raised:

 raise RuntimeError("Keyboard is not on screen")
  RuntimeError: Keyboard is not on screen

[Richard Huddie (rhuddie)]

Some further info. The following setting can force the osk to remain hidden:

gsettings get com.canonical.keyboard.maliit stay-hidden

During the test, this setting is set to true. But when the test is not running this setting is false.

So it seems that this setting is being applied by Unity, because autopilot is exposing a fake keyboard.

[Michael Zanetti (mzanetti)]

Is there really a use case for using the autopilot keyboard *and* the OSK? Except, of course, when testing if the OSK correctly hides when you plug a proper keyboard. IMO tests that rely on the OSK should not create an keyboard in autopilot and vice versa.

That said, there seems to be discussions about allowing the OSK to show up even with a keyboard plugged. But most likely not just showing it nevertheless, but rather some mechanism for the user to bring it in on a touch screen additionally to the attached physical keyboard. There's desig as well as SDK work missing for that still...

[Richard Huddie (rhuddie)]

There are a couple of cases where the simulated keyboard is required, even if the OSK is being used. For example, when moving the cursor to the end of a line of text in a field, this is much easier to do if you can use the arrow keys from the simulated keyboard, which are not present on the OSK. This is how some of the text selection methods are implemented, even though it is not ideal to use both types of keyboard. Hopefully this won't cause issues in future, I know it used to work previously.

I can confirm that by setting the 'stay-hidden' setting back to false after unity has set it to true, the OSK is displayed and the test will pass as normal. So hopefully if Autopilot over-rides this setting before running a test the OSK will work as normal.

[Ken VanDine (ken-vandine)]

Does this need to be fixed in uitk-autopilot or autopilot? Please update the bug with the appropriate project.

[Richard Huddie (rhuddie)]

Re-assigned this bug to autopilot as it seems that after a keyboard is created by autopilot, the following command needs to be run to disable the osk hiding:

gsettings set com.canonical.keyboard.maliit stay-hidden false

[Albert Astals Cid (aacid)]

This also makes unity8.shell.tests.test_helpers.DashHelperTestCase.test_search fail

[Albert Astals Cid (aacid)]

The unity8 autopilot stops failing with https://code.launchpad.net/~aacid/autopilot/keyboard_when_needed/+merge/268322

[PS Jenkins bot (ps-jenkins)]

Fix committed into lp:autopilot at revision 569, scheduled for release in autopilot, milestone 1.4