I’m unable to figure out how to get Kee to fill out the correct password field for https://accounts.intuit.com/ since they updated to mutli-step. It seems Kee is properly matching the site URL because it shows up in the list, but it’s not finding the password field as it won’t fill it out. Looking at the HTML, it seems they have a whole bunch of hidden password fields for different workflows, like resetting passwords and such. I went and excluded them all in the per-site settings. Then I also included the ID for the real password field which is ‘ius-sign-in-mfa-password-collection-current-password’ but it still doesn’t work.
Here is my current per-site config for Intuit.
INCLUDE:
Match Form ID: ius-form-sign-in,ius-sign-in-mfa-password-collection-form
Match Text ID: ius-identifier,ius-signin-userId-input,ius-sign-in-mfa-password-collection-current-password
EXCLUDE:
Match Text ID: ius-password,ius-sign-in-mfa-password-collection-password,ius-sign-in-mfa-password-collection-confirm-password
Including or excluding the whole form isn’t going to help (Including or excluding forms). Instead, add the correct ID to the password field in the entry’s Kee > Form fields setting.
I’m not sure if this is what you mean, but I disable autofill entirely always so the password is never accidentally put into a field it shouldn’t be entered into. I always click the little Kee icon to fill in passwords. The Kee icon does not show up on Intuit’s page’s login screen for me. So I think the issue is just that it’s not detecting the password field correctly. Not sure why.
Yeah that’s what I meant. Without an account I am unable to reach the password field so was only able to test on the username field. Presumably the problem is only with the password field so I am unable to explore the solution further without an account. Check the debug logs but I still suspect that the reason it’s not working is that the form containing the field is being excluded by either your site-specific or the general exclusion lists so make sure no other field (nor the form element itself) is matched in one of the exclusion lists.
How do I check debug logs on my end? I’m having a couple other sites I can’t figure out why they don’t work, but if there’s a way I can troubleshoot on my own other than just guessing, that’d be awesome!
I really don’t understand what is happening. I tried two other password fillers and they worked as expected. I’d rather use KeePass + Kee, though. Here is some info from the page source and logs. I did notice there is more than one password field in the source. The “change password” field is hidden but it exists in page source. I tried creating custom site options and excluding those fields from matching, but that didn’t help either.
OK I figured it out. The issue is that Intuit has three password fields in the form. Two of them are for changing your password (current, new password). I knew this before and I had set the input ID specifically to the correct one, the login one. However, Kee wouldn’t offer to fill it. Here’s the trick that worked. The two password fields for changing your password were hidden using visibility:hidden style. Once I changed the style of all password fields to be visible, Kee offered to fill only the third password field, which is exactly what I wanted.
So it seems that even if the password field you want to fill is visible, but others are invisible, it will not offer to fill the form. Is this a bug or intended behavior? How do I get it to ignore visibility status of elements in cases where it causing issues?
I think that the relevance of the form is being reduced by the multiple hidden password fields and therefore the form is ignored even though one field does match.
It’s counter-intuitive but if you could set an additional form field entry for one of the “new password” fields then the additional match accuracy that comes from that being found in the page might trick Kee into thinking the form is more relevant. I’m not certain that will work though and it might have other undesirable side-effects but it could be worth a try.
More long-term, we could experiment with a new version of Kee that slightly increases the visibility bonus applied to fields (currently it’s 35 on line 235 of formFilling.ts). All of the figures in that algorithm are semi-arbitrary and only really stay the same while it looks like everything is working well. Bumping that up to 40 for example, should resolve this specific case but until we run some detailed tests, we can’t be sure if it will also have a detrimental side-effect on other situations (making Kee pick the wrong form more often).
I don’t plan to make any further Kee releases until I’ve confirmed that it will be possible to release a viable version in 2023. I’m making a lot of progress on scoping out the immense scale of changes that will be required in the next 6 months but have yet to reach a level of certainty that is sufficient for me to switch to working on this full time, which is what will most likely be required to meet Google’s new requirements (“MV3”). I’ll keep this issue in mind if I am able to continue developing the extension though.
Oh jeez, I didn’t know Google was throwing a wrench into extension development again. I just read about MV3 and it sounds like a trainwreck. I guess I might have to switch to Firefox.
