Is this a reincarnation of  bug 514636 ?
What happens if one adds and deletes a space at the end of the password, once the password has been filled by 1password? Does Chrome recognise the change then?

Unfortunately there's no way to answer that question because 1password submits the form after it fills it.

If I manually paste the new password into the field before I submit it (ie, not use 1password), then Chrome will ask me to update it.

Thanks for the clarification.

Reading #3, one explanation for the difference could that 1password submits the form in a different way than the submit button does. It sounds unlikely, bot not impossible. A log from chrome://password-manager-internals/ kept open during the fill&submission with 1password could clarify this.

I'm marking this as Available to put it into the team's TODO queue.

I captured logs of filling the login form with 1password (of course, i've since fixed chrome's view of the password so it says the password matched). Are they helpful? I'm a little wary of attaching them here in a public bug.

Should i try to change my password again and get Chrome out of sync and then take a log? Would that give you more info?

I don't think you need to change your password, the important thing would be to capture the logs during submission. In more detail, I'd like to have the logs from the following:
1. Open ooma.com.
2. Open chrome://password-manager-internals in a separate tab.
3. Let 1password fill & submit (which I understand happens through a single user action).
4. Copy out the logs from the second tab.

That will tell us what submission Chrome observed, if any. Ideally, for comparison, it would also help to have the logs from the following for comparison:

1. Open ooma.com.
2. Open chrome://password-manager-internals in a separate tab.
3. Let Chrome fill (or type the credentials by hand) and submit the form by clicking its submit button or pressing enter in the password field.
4. Copy out the logs from the second tab.


You do not have to share the logs here, of course. If you feel comfortable sending them to me in an e-mail, I'll check them out and only post the conclusion about Chrome's behaviour here.

(Having said that, the logs were designed to avoid any private information. They contain neither username nor password values, only the host of the form origin and action URLs, which we already know are ooma.com, and the form element names.)

Here's the log i took yesterday with 1password filling and submitting the form.

Deleted: password manager logs 3.5 KB

password manager logs 3.5 KB View Download

Here's chrome submitting the same page with the chrome password filled in for comparison.

Deleted: chrome password fill 3.6 KB

chrome password fill 3.6 KB View Download

Thanks for the logs!

From them it looks like Chrome updated the password silently in both cases ("Decision: SAVE the password") and the observed submission was the same in both cases.

So the issue is in Chrome disregarding the input done by 1password's JavaScript.

@dvadym -- does this sound like the protection against website mangling the user's input? If so, it's likely not just Mac-specific. But I also have no good idea what to do here, as disabling the protection will break a number of sites.

As response to #10: yes, it is probably the protection again mangling the user's input. 

We need to check whether chrome updates |PasswordAutofillAgent::field_value_and_properties_map_| in  PasswordAutofillAgent::UpdateStateForTextChange (https://cs.chromium.org/chromium/src/components/autofill/content/renderer/password_autofill_agent.cc?q=UpdateStateForTextChange&sq=package:chromium&l=655) when 1Password fills the password into the field. 

If yes, we probably have to leave it as it is, because we can't remove the protection.

Mark as good first bug. 

Re-discussed the issues. We cannot trust Javascript changes (only user and autofill). So, mark as WontFix.