798: routing back to itemlist on login/search/feedback forms

[eliserichards]

Fixes #798

There are a number of things that are being cleaned up as part of this PR. The original issue was tracking the keyboard being minimized when clicking in text fields, and in some cases, being routed back to the item list.

Below you will find my notes and analysis which lead me to find the source of the original issue: the AutofillService was being triggered when a potentially fillable text field was encountered (e.g. the search text field or editable username/hostname/password fields). The mitigation for this was to mark those fields as not autofillable.

In addition to that, this PR fixes the following:

• dispatch the AutofillStart action at the end of onConnect() instead of the beginning
• add missing routes for locking that caused crashes
• use TextInputEditText in place of EditText

---

Testing and Review Notes

This is easily reproducible on Pixel 2 with search and edit.

Search

Probably related to locking or routing... we're seeing the DataStore.state being updated, which causes the Unlocked workflow to send the user to the ItemList:

private fun dataStoreToRouteActions(storageState: DataStore.State): Optional<RouteAction> {
        return when (storageState) {
            is DataStore.State.Unlocked -> RouteAction.ItemList
            is DataStore.State.Locked -> RouteAction.LockScreen
            is DataStore.State.Unprepared -> RouteAction.Welcome
            else -> null
        }.asOptional()
    }

The state could be set to Unlocked in three places in the DataStore:

• updateCredentials()
• unlock() - coming from FingerprintAuthAction in the LockedPresenter
• handleLock()

Todo:

• add route from fragment_filter -> fragment_locked
• add route from fragment_filter -> fragment_item_list (does this solve the issue?)

Edit

Caused by: java.lang.IllegalStateException: Cannot route from mozilla.lockbox:id/fragment_item_edit to mozilla.lockbox:id/fragment_locked. This is a developer bug, fixable by adding an action to mozilla.lockbox:id/graph_main.xml and/or AppRoutePresenter
        at mozilla.lockbox.presenter.RoutePresenter.navigateToFragment(RoutePresenter.kt:145)
        at mozilla.lockbox.presenter.RoutePresenter.navigateToFragment$default(RoutePresenter.kt:125)
        at mozilla.lockbox.presenter.AppRoutePresenter.route(AppRoutePresenter.kt:90)
        at mozilla.lockbox.presenter.AppRoutePresenter$onResume$1.invoke(AppRoutePresenter.kt:52)
        at mozilla.lockbox.presenter.AppRoutePresenter$onResume$1.invoke(AppRoutePresenter.kt:32)

Todo:

• add route from fragment_item_edit -> fragment_locked

[eliserichards]

Updated investigation:

• when a user clicks on the search icon and the fragment_filter is displayed, the autofill workflow is being triggered from LockboxAutofillService (onConnected())
• this dispatches a LifecycleAction.AutofillStart action, causing us to evaluate locking in the DataStore (where this.foreground contains the AutofillStart action):

lifecycleStore.lifecycleEvents
            .filter { this.foreground.contains(it) && stateSubject.value != State.Unprepared }
            .subscribe { this.handleLock() }
            .addTo(compositeDisposable)

• because of this, the app is routing the user back to the item list via dataStoreToRouteActions() (see notes above under "Search")

Questions:

• should autofill be connecting when we search? why is it firing then and not on app startup?
• why doesn't the logic recognize that the app is already foregrounded AND unlocked? we shouldn't have to unlock again.

[jhugman]

Looks great! Please land.

[jhugman]

Rawk

[jhugman]

Is this what is required? Will check the issue.

[eliserichards]

Need to follow up with UX on whether we're routing to ItemList, ItemList with a toast notification ("You updated XXXX credential!"), or the item detail. Will confirm.