2064266 - Unguarded closeSoftKeyboard() in BasePage fails efficiency UI tests with PerformException

Status: RESOLVED FIXED

(Firefox for Android :: UI Tests, defect)

Description

[Jackie Johnson]

BasePage and two page objects call Espresso's closeSoftKeyboard() directly. That throws PerformException: Error performing 'close keyboard' on view 'view.getRootView() to equal view' whenever the focused view's root is not the one Espresso expects, which happens routinely when no editable view has focus -- on the homepage, or after a dialog takes focus.

Hiding the keyboard is only ever a convenience for the assertion that follows, so failing to do it should not fail the test.

Two tests fail locally on this today (full ui/efficiency package run, MediumPhone.arm API 34 emulator):

• SettingsGeneralTest.verifyFontSizingChangeTest -- via BasePage.mozVerifyAnyContainsText
• SettingsSearchTest.verifyCustomSearchEngineCanBeAddedFromSearchEngineMenuTest -- via SettingsSearchAddSearchEnginePage

Both pass in CI, so this does not show up on Firebase Test Lab -- presumably because of different focus/root behaviour there. It only bites locally, which is where developers run the suite while converting tests.

Unguarded call sites in the efficiency framework:

• ui/efficiency/helpers/BasePage.kt (2, in mozVerifyAnyContainsText and mozVerifyNoneContainText)
• ui/efficiency/pageObjects/SettingsAutofillPage.kt
• ui/efficiency/pageObjects/SettingsSearchAddSearchEnginePage.kt

Fix: add a protected fun dismissSoftKeyboard() to BasePage that wraps the call in runCatching and logs the swallowed exception, and route those four sites through it. Both page objects extend BasePage, so no duplication is needed.

There are a further 13 unguarded calls in the legacy ui/robots/* and ui/*Test.kt files. Those are left alone here to keep the patch reviewable; they are a reasonable follow-up.

Comment 1

[Jackie Johnson]

Attachment: Bug 2064266 - [efficiency] Do not fail a test when closeSoftKeyboard() cannot hide the keyboard r=isabel_rios,aaronmt

Espresso's closeSoftKeyboard() throws PerformException when the focused view's root is not
the one it expects, which happens whenever no editable view has focus - on the homepage, or
after a dialog takes focus. Hiding the keyboard is only ever a convenience for the assertion
that follows, so failing to do it must not fail the test.

Two tests fail locally on this today, and pass in CI, so it only bites developers running
the suite: SettingsGeneralTest.verifyFontSizingChangeTest via
BasePage.mozVerifyAnyContainsText, and
SettingsSearchTest.verifyCustomSearchEngineCanBeAddedFromSearchEngineMenuTest via
SettingsSearchAddSearchEnginePage.

Adds BasePage.dismissSoftKeyboard(), which wraps the call in runCatching and logs what it
swallowed, and routes the four call sites in the efficiency framework through it. It is
protected rather than private so the two page objects, which extend BasePage, use the same
helper instead of repeating the guard.

A further 13 unguarded calls remain in the legacy ui/robots/* and ui/*Test.kt files. Left
alone here to keep the patch reviewable.

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/4edfa99bcb58
https://hg.mozilla.org/integration/autoland/rev/67ab1de4c569
[efficiency] Do not fail a test when closeSoftKeyboard() cannot hide the keyboard r=aaronmt

Comment 3

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/67ab1de4c569