Let's break this cycle as it's not helping anybody.
I've read the conversation so far and done a reasonable amount of testing and here is what I've found.
Summary: Due to how iOS Chrome works there is indeed an issue but it seems to be limited to iOS Chrome on the iPad.
Detailed explanation. I created the account and saved the Login item on my Mac. I just find it easier. I could have created the Login item in iOS Safari as well though but the issue with filling in iOS Chrome on the iPad extends to saving in iOS Chrome regardless of the device. The steps detailed at Fill and save using the extension (iOS) work in iOS Safari and the username and password are extracted from the page just like they are on the Mac. The same is not true for iOS Chrome.
I then tested filling in 1Browser, iOS Safari and iOS Chrome and I tested both on my iPad and my iPhone. I could successfully log in everywhere except for the combination of iOS Chrome on an iPad, iOS Chrome on the iPhone worked.
So why is iOS Chrome a factor? There are two distinct versions of the 1Password iOS extension. One is for iOS Safari and is used by iOS Safari, Firefox and Brave. It's essentially the same core code as our desktop extension uses. Then there is a generic iOS extension where the supporting app provides a URL and in return we supply a username and password and the rest is up to the app. So in iOS Safari we pass fill instructions to our extension which then performs the same filling steps as it does on the Mac. iOS Chrome does not support this, they only added support for the generic one and so we pass the username and password but it's up to iOS Chrome as to where the data is placed and we have zero control. I don't know what iOS Chrome on the iPad is doing and why it is doing it differently but it is.
If you try iOS Safari I bet you find as I do and it works. Unfortunately any changes here will have to come from the iOS Chrome developers as they don't support our iOS Safari extension. Could iOS Safari be a suitable alternative given the issue?
I will try safari to see how it works,
Sorry for the miscommunication earlier. I'm glad lil bobby was able to put everything into context. I believe Safari should work for you as you expect since it does here, but let us know either way.
I’m able to login with Safari.
I'm guessing you'd really have liked to use your preferred browser but given the issue is with iOS Chrome is Safari a reasonable alternative for now?
I can live with it, I just need to remember to switch to safari when I log in to that forum.
Why does Chrome work on other forums but not that one?
Now that I don't have an answer for I'm pretty good at picking apart 1Password's filling behaviour because I have access to the filling code and I can build a version of the extension that allows me to easily debug what is going on. Chrome's filling behaviour is as closed off to me as it is to you. It appears to fill both the fields so what it is also doing or not doing that results in that error message I don't know or why it only impacts when on an iPad and not an iPhone.
What I can say is it isn't the first time I've seen Chrome's way of doing things result in differences. Thankfully not too often but this isn't the first time I've had to write that filling works everywhere but in iOS Chrome so it's on them to improve things. That's just the reality of them not wanting to use our iOS Safari extension and retain control of filling the fields.
It looks like it’s not just the KeyboardMaestro site that Chrome has managed to break the logins with.
I’ve just found out that I cannot log into https://cycling74.com/ with Chrome and 1PW, UNLESS I manually copy and paste my login credentials from 1PW into the login dialog.
When I use Safari to log in to https://cycling74.com/, with 1PW, I have no problem.
@cappy: That's troublesome. Out of curiosity, is it working for you with Chrome on an iPhone again but not the iPad? If you report it to the Chrome team, a detail like that could help them track down the cause.
I haven't tried it on the phone yet.
I'll report this to the Chrome devs, if I can find the bu report site.
@cappy: It looks like mobile bugs also go in the Chromium project: https://bugs.chromium.org/p/chromium/issues/list
Thanks, but that's a bit confusing. I'm not sure if that's the right place. I don't want to mislead the devs. Will look for Chrome bug reports tonight, after work
Hopefully finding a second site so soon after the first is more just being unlucky than an indicator of how frequently you should expect to find this occurring within your list of go-to places. Unfortunately it is the case that our hands are tied. If filling works in iOS Safari when our extension is used then we've done as much as we can.
As somebody that never felt compelled to move beyond iOS Safari can I ask what you like about iOS Chrome? It is genuine curiosity given I only ever hear of iOS Chrome when somebody writes in about a filling issue which I'm sure is far from the total picture.
Basically it’s a carryover from MacOS. I had so many problems with Safari (spinning beach balls)there, that I rarely use it on the Mac.
Also, I use chrome on Windows at work, and often have many of the same tabs open on both platforms. The tabs are synced across multiple platforms.
I just came across this, I’m wondering if this may have anything to do with the issue I’m seeing on Chrome on iOS.https://nakedsecurity.sophos.com/2018/01/03/ad-scripts-track-users-via-browser-password-managers/
@cappy: I don't believe that applies in this case, as they're referring to autofill and extensions in desktop browsers. iOS extensions work very differently. But I'm glad you shared that article, because it's interesting anyway! But, peripherally, it's entirely possible that Google chose to go their own way in this area for some business reason, though I couldn't tell you exactly what that might be. Maybe they're able to reuse more of their code this way.