Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue/126 - Android Autofill #141

Merged
merged 17 commits into from
Apr 21, 2019

Conversation

se1exin
Copy link
Member

@se1exin se1exin commented Feb 9, 2019

This PR should be considered a Work In Progress for two reasons:

  1. Compared to the iOS implementation and experience, so far Android is only about half way. The simplest form of AutoFill is working - with credentials being offered on-screen in the app being logged-into (e.g. Google Chrome). However, kicking the user temporarily into the Buttercup app to choose a credential (like in the iOS implementation) is not yet implemented, and appears to be a much larger undertaking than it was with iOS. Whilst it should indeed be possible to implement the kick-back to Buttercup to choose an (up-to-date) credential, I thought I would put the PR up in case you wanted to get at least what has been implemented into release soon rather than waiting for the whole thing to be complete.

Edit: Point 1 is now working as well

  1. In case you are keen to release based on point 1, there is one other factor to consider first. On Android there is no obvious way (that I can find) to set Butercup to be the AutoFill provider in the Android Settings (which can be a labyrinth at the best of times). The recommended way in the Android dev docs is to request if the user wants to setup autofill, and then programmatically switch to the AutoFill selection settings in the Android Settings app, at which point the user can toggle Buttercup on. I am currently immediately switching directly to the Android Settings page as soon as the app loads, which is obviously a terrible idea, so I would like to formally request for feedback on how, where, and when the app should ask the user if they would like to enable AutoFill. I think this also applies for iOS as well, as currently it is up to the user to manually go and enable AutoFill in the iOS settings.

Edit: Point 2 has been implemented using the same approach as enabling Touch ID on an Archive

Finally, I'm also going to suggest that the conversation around point 2 be held in the original issue #126, as I feel it is more likely to be seen and participated by the community there.

Closes #71, Closes #126

This was referenced Feb 9, 2019
…th Android sharing redux state between main app and autofill app.
@perry-mitchell
Copy link
Member

Great stuff @se1exin! I'm not surprised that it sounds more complicated. Thanks a lot for looking in to this.. We're happy to not rush things, if it's your opinion that it's still possible to improve the UX.

Let's continue in #126!

@se1exin se1exin changed the title [WIP] Issue/126 - Android Autofill Issue/126 - Android Autofill Feb 16, 2019
@se1exin
Copy link
Member Author

se1exin commented Feb 16, 2019

@perry-mitchell This PR is no longer a WIP - its now ready for testing and hopefully merging!

release {
manifestPlaceholders = [usesCleartextTraffic:"true"]

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've not done much Android or React Native development, but is it normal that a password manager needs to enable non-HTTPS communication? Do you know what plaintext HTTP resources this app requests?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good find @jokeyrhyme! Cleartext was needed to allow access to the metro bundler in dev - I must have forgotten to switch it back to off for release.

This is fixed in feccc8a

@jokeyrhyme
Copy link

Hmmm, the build is failing, which seems normal for this project: https://travis-ci.org/buttercup/buttercup-mobile/builds/494137819

However, previously, the "Node.js:8" job was passing: https://travis-ci.org/buttercup/buttercup-mobile/builds/481638329

The rest of this looks fine to me (for what it's worth) :)

@se1exin
Copy link
Member Author

se1exin commented Feb 16, 2019

@jokeyrhyme I've fixed the nodejs test, but after a few attempts was not able to get iOS and Android tests to work. The tests we're already failing before I came along, and I'm not all that familiar with travis, so I'll defer fixing those to someone with more experience.

@jokeyrhyme
Copy link

@se1exin fair enough, yeah, looks good :)

@perry-mitchell perry-mitchell self-requested a review February 20, 2019 18:10
@perry-mitchell
Copy link
Member

Hmmm, the build is failing, which seems normal for this project: travis-ci.org/buttercup/buttercup-mobile/builds/494137819

Yeah the tests are a mess.. they pass locally but the CIs seem to have major issues. That's a separate issue 😅

This PR is no longer a WIP - its now ready for testing and hopefully merging!

Amazing! I'll make sure it's taken care of this week!

Copy link
Member

@perry-mitchell perry-mitchell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just a couple of minor items!

source/shared/autofill.js Outdated Show resolved Hide resolved
source/shared/autofill.js Outdated Show resolved Hide resolved
source/shared/autofill.js Outdated Show resolved Hide resolved
export function autoFillEnabledForSource(sourceID) {
return new Promise((resolve, reject) => {
if (autoFillAvailable) {
return AutoFillBridge.getAutoFillEnabledSources().then(autoFillSources => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And this too.. Otherwise perhaps wrapping it in something like:

return Promise.resolve()
	.then(() => {
		// ...
		return false;
	});

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this one - the promise resolves on all paths, unless I'm missing something?

export function getAutoFillSystemStatus() {
return new Promise((resolve, reject) => {
if (autoFillAvailable) {
return AutoFillBridge.getAutoFillSystemStatus().then(isAutoFillEnabled => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here

Copy link
Member Author

@se1exin se1exin Mar 4, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again for this one - the promise resolves on all paths, unless I'm missing something?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean it's alright of course, it's just a bit weird seeing the promise being returned when using the new Promise((resolve, reject) => ... format. I'm fine with this as it works of course.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alternatively (maybe):

export function getAutoFillSystemStatus() {
  return autoFillAvailable ? AutoFillBridge.getAutoFillSystemStatus() : Promise.resolve(false);
}

index.shared.js Outdated Show resolved Hide resolved
@perry-mitchell
Copy link
Member

@se1exin Sorry for the delay.. Has been a busy week and I'm recovering from a bug. I'm keen to get this released.. It's a huge PR, and definitely over my head. My idea is that once again, after it's reviewed, I'll merge it to a holding branch where we'll test it before going to master.

@se1exin
Copy link
Member Author

se1exin commented Mar 4, 2019

@perry-mitchell all good, hope your feeling better!

I've adding the missing resolves (not sure how I missed them originally..), however I'm not sure about the last 2 in the review (see review comments). Happy for you to just re-write the Promise logic for those if your can see an issue that I can't :)

@sallar
Copy link
Member

sallar commented Mar 4, 2019

Thanks @se1exin for this! I've just tested it, and the autofill works great. However I have a slight problem with a few random errors that keep occurring, which Im not sure are caused by this PR. But I'll investigate a bit more.

Edit: I have found a few issues:

2019-03-04 21 24 58
2019-03-04 21 24 56
2019-03-04 21 24 53
2019-03-04 21 24 48

Copy link
Member

@sallar sallar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work! Just a slight change needed from my part

const itemSystemSettings = "Android Settings";
const itemCancel = "Cancel";
return Promise.all([getAutoFillSystemStatus(), autoFillEnabledForSource(currentSourceID)]).then(
results => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

maybe destructure this instead of assigning new constants later:

Suggested change
results => {
([autoFillEnabled, archiveEnabled]) => {

Copy link
Member

@perry-mitchell perry-mitchell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me!

export function getAutoFillSystemStatus() {
return new Promise((resolve, reject) => {
if (autoFillAvailable) {
return AutoFillBridge.getAutoFillSystemStatus().then(isAutoFillEnabled => {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I mean it's alright of course, it's just a bit weird seeing the promise being returned when using the new Promise((resolve, reject) => ... format. I'm fine with this as it works of course.

@se1exin
Copy link
Member Author

se1exin commented Mar 13, 2019

Hey! @perry-mitchell @sallar

Sorry for the delay in getting back to you both on this, work and life has been quite busy for the last few weeks. It also doesn't seem to be easing off so at this point I'm not sure when I will get a chance to address the feedback items sorry. Not sure what I can do to help at the moment but thought I would let you know so your weren't left hanging.

@perry-mitchell
Copy link
Member

Thanks @se1exin - We know the feeling! We'll take care of the final adjustments shortly. Take care 👍

@seddarj
Copy link

seddarj commented Apr 21, 2019

Great work 👏 ! Can't wait to see this merged!

@perry-mitchell perry-mitchell changed the base branch from master to android_autofill April 21, 2019 17:51
@perry-mitchell perry-mitchell merged commit 788c4b4 into buttercup:android_autofill Apr 21, 2019
@hayr-hotoca
Copy link

Hi great work btw @se1exin !

But how do you retrieve the domain name from browser apps? My machine the getWebDomain() method always return null?

@se1exin
Copy link
Member Author

se1exin commented Jan 1, 2022

Hi great work btw @se1exin !

But how do you retrieve the domain name from browser apps? My machine the getWebDomain() method always return null?

Hi @lincdh thanks, it's been a few years since I implemented this so my memory isn't very fresh on the inner details, but the first think I would check is your service config contains the apps you want to read from: android/app/src/main/res/xml/autofill_service_configuration.xml

Good luck 🙂

@hayr-hotoca
Copy link

hayr-hotoca commented Jan 2, 2022

@se1exin I tried to create another android project to test your code but the same result. Did it looks somewhat like below when you debug?:
Also if you have spare time could you have a look at my autofill implementation(mostly with your code) at https://github.com/lincdh/autofilljava? Thanks!
image

@perry-mitchell
Copy link
Member

@lincdh Sorry, this isn't the right forum for debugging your project. Please use this codebase as a reference for your work, however. Best of luck :)

@buttercup buttercup locked as resolved and limited conversation to collaborators Jan 3, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants