Explore implementing Autofill API Provider about lockwise-android HOT 9 CLOSED

@eliserichards the onboarding story is linked above: #55

from lockwise-android.

We might be able to hijack the authentication dialogfragment to display a list of entries with search functionality instead, but we'll be working around the intention of the API design to do so & I don't want to promise that it would work :) it might be worth further exploration as a follow-up to the autofill work.

from lockwise-android.

Discussed using this as an "explore" chore to break out all the work needed into separate stories...

from lockwise-android.

@nickbrandt @changecourse heads up: maybe @eliserichards can correct / confirm my reading of the documentation here, but the Autofill Credential Provider system we are using on Android does not have a way to let you provide a "Search your entries" option along with the list of entries. So I think this feature will really be constrained to "show credential(s) when matching, fingerprint or PIN verify when the app is locked".

from lockwise-android.

Confirming all ACs are covered:

• Should be prompted during onboarding to set up autofill for apps and websites (direct user to settings/accessibility area). - #55 (onboarding), #214
• Should present user with ability to “autofill from Lockbox” when clicking into a username or password field on apps or sites (if enabled). - #56, #215
• Should be able to select an entry from the list of options and have that populate both username & password fields. - #215
• If no match is found, ‘search’ option should open Lockbox app. - Waiting for feedback from Nick/Ryan (see Sasha's comment above)
• Should adhere to Android Design Guidelines - yes
• Should honor lock state and settings - #216

Issue #217 needs more content: a useful error message when a user attempts to save credentials through autofill UI. Can we disable this system prompt? (answer: yes, see nerdyverde's comment in openid/OpenYOLO-Android#127)

from lockwise-android.

the Autofill Credential Provider system we are using on Android does not have a way to let you provide a "Search your entries" option along with the list of entries. So I think this feature will really be constrained to "show credential(s) when matching, fingerprint or PIN verify when the app is locked".

So just to be clear, we're discussing this screen here:
https://mozilla.invisionapp.com/share/3SN35UHWJDX#/317568427_Autofill_-_App_-_No_Matches

And in tapping that search prompt displayed, it would direct you to the app, where after unlocking you would just be presented with the entry list for view? Does this mean that we can provide a way for you to open the app (via our search prompt) but that you cannot then be redirected to fill, once you've selected an entry? If yes, I think that's ok... not ideal, nor parity with iOS, but a fallback due to this functionality not being currently possible.

Follow-up question: What does this mean for this state, where we have "Search Lockbox" presented at the base of a list of matching entries? If we cannot use this as an alternate means for autofilling, we may need to reconsider this implication.

FWIW, other password managers that we've tested allowed for credential list access (if no matching entries were found) but perhaps they are using a different implementation from OpenYOLO? See below, for a concept around searching while in the context of an external app.

from lockwise-android.

@changecourse Great questions!!! Yes, this has implications for the No Matching Entries screen that you linked from invision. A few answers / points of clarification:

• We are using the AutofillService API baked into Android, which is not the same thing as OpenYOLO or the Accessibility APIs.
• The AutofillService API does not allow you to display anything other than an authentication dialog for things like Fingerprint or PIN auth; you can't open your app at all as far as I can tell from my exploration.
• I looked into the documentation for the other credential providers; I think that most of them are using either OpenYOLO (haven't completed my readthru of that documentation) or Accessibility APIs (which we've decided against) for the custom behavior.
• For the "No matching entries" state that you mention and all other overlays within a login page, the system provides all of the UI (haven't explored what exactly it is). The only UI that we fully control is the authentication dialog (presumably our fingerprint or PIN fragment).

I hope that helps; it might be worth scheduling a quick meeting to go over these findings to talk about the design implications.

from lockwise-android.

@sandysage & @linuxwolf, per our conversation today (with @sashei, @eliserichards, and @nickbrandt) we're going to hold off on implementation of the search/manual support for searching for entries in autofill, due to the limitations of the autofill api, though further exploration may find that this is easier or harder than expected to do...

#217 is perhaps a better enhancement to prioritize instead; being able to save new credentials from both apps and browsers into Lockbox. @sandysage to decide whether or not to uplift accordingly.

Some of the UI (outside of the authentication screen) may not be able to be custom, as our designs would indicate. This will be acknowledged during our future UX review of the PR.

from lockwise-android.

Reviewed and ready to close and promote the newly created autofill stories and schedule the work. Thanks everyone!

from lockwise-android.