Cannot save login for U.S. Trust account page

Hi @cdp,

So our standard filling technique does indeed seem to have trouble with this site. We perform various actions before and after setting the value of a particular field (how we fill) and my understanding is these actions have built up over time as the set of actions that allow us to be compatible with the majority of sites out there. In other words these actions help mimic certain behaviours the site expects to see and by doing this we help them accept what we're doing on your behalf. On this site though these actions seem to be causing an interaction and as you say, the field clears as a result. So there will be work needing done here to improve not the compatibility with their page.

Now I'm not a customer of U.S. Trust, indeed I'm not even in the right country to be one but what little I've been able to test would suggest that Auto-Type should help. The reason I'm thinking this is when I try a standard filling attempt I find like yourself that the field seems to either remain blank or is erased and then I get the following error message when it tries to submit

Please enter required information.

Now if I enable the option Use Auto-Type in web browser for this item I instead get a different error message when I try to submit. With Auto-Type I get the message

Invalid User ID. Please retrieve your User ID or contact us for assistance.

That error message isn't entirely surprising given I'm not a customer and the user ID I'm testing with is totally fictitious. So I'm wondering, when you sat enabling Auto-Type doesn't help does anything change at all and how are you using Auto-Type? One way is to enable the option I mentioned earlier and when you try to fill using this Login item it will use Auto-Type. This method isn't perfect for this situation though for the following reason. It assumes the username and password fields are on the same page so it first uses Auto-Type to "type" in the username, then the tab key to move focus to the next field, which we assume is the password field, before it then uses Auto-Type to type in the password. Given the nature of their login page process this isn't the best option. On our page Using auto-type there is a section titled Field-level auto-type. If you try using this does the site behave any better?

Thanks for the update, @cdp. I'm glad you have a process that works for you for now. I would love to get a peek at that password page, though, because unless it has multiple password fields or some other very crazy logic, 1Password should be able to fill the password field from a login that wasn't saved on the password page.

You're right that it does seem to be financial institutions that have the most Rube Goldbergian of login processes. (Here's one example I investigated yesterday if you're curious as to how deep the rabbit hole can go…) We would love to work with financial institutions to create real security for every website user. There are some other interesting possibilities on the horizon that we're keeping our eyes on that might help push the financial institutions in a better direction. We shall see. :)

Do you guys work up specific processing for troublesome websites and distribute a template through software updates for the program to use that customizes the approach for dealing with those websites?

We take a look at a variety of things related to website filling, and you're right that it is a big job to keep up with everything. But it's also a lot of fun to investigate and see where we can improve. Sometimes we do have to add some special handling for special websites to get them to work better, and we have some planned improvements to help us be more agile with them in the near future. But when we encounter a particular problem site, we first look to see if there is some generic way we can improve our form filling logic so that 1Password works for the problem site in a way that might also benefit other sites that use similar coding techniques. We add these as new tests to our automated testing suite to make sure the improvements do not regress other sites.

So, while we will add site-specific code when needed, we're more interested in generic filling improvements. More interesting still is when we notice a website development pattern that allows us to fix one site and by doing so improve filling in many other places. One example that springs to mind is when we figured out how to properly fill credit card expiration dates in Amazon's form for adding new payment methods. They were using a particular pattern we hadn't considered before and then we noticed a lot of other sites were using the same pattern, so fixing it on Amazon fixed it on several other prominent sites as well.

I love that you're interested in this stuff! I hope that sheds a little light on our process. Let us know if you have any other questions.

Greetings @cdp,

Thank you for posting back. Your post prompted me to look at this site again and I'm grateful I did.

We see all sorts of crazy behaviour in the sites that get brought to our attention and we do our best to work with the craziness when it seems to be a common practice. One element of crazy is the fact that a invisible field can sometimes be used and we occasionally need to fill. What looks like a simple login page for the username only actually holds five input fields hidden from the user that are all of type password. So when we try to fill the page and the Login item has both a username and password present we do our best to fill both and that's what is happening here. We fill the username first and then we attempt to fill your password into one of these hidden fields. This has the side-effect of clearing the username, probably because the site didn't like us touching that hidden field as you say. So it isn't an HTML ID mismatch, it's 1Password desperately trying to fill the password and finding fields that are of the correct type. The presence of the password field in the Login item is all that is required to set this behaviour off.

I'm not sure what the answer here is. @jxpx777 will have a much better idea than due to his keen eye and intelligence. I suspect this will be an excellent learning point for myself as to what we might be able to do.

It's really like juggling sometimes, do x to try improve filling in y number of sites but then later discover somebody does things completely the other way round and you've broken it there. Every site brought to our attention though helps us improve the extension and reliability of the filling behaviour :smile: