[Chrome] 1Password filling does not replace field contents
It happened quite a few times to me already, just remembered reporting it today:
When on a login page, Chrome prefills the username and password fields with information from their password manager, when you then delete the content of the "username" field, right click, invoke 1Password and fill from it, the content in the password field is not being replaced with info from 1Password, possible resulting in "wrong password" messages.
I just had it happen on https://www.thetvdb.com/index.php?tab=login but possibly happens on other sites as well.
1Password Version: 7.0.539.BETA
Extension Version: 4.7.1.3
OS Version: Windows 10 1803
Sync Type: Not Provided
Comments
-
Greetings @Stanzilla,
The only time I'm aware that 1Password won't replace the contents of a field is if the current field value matches what 1Password would fill into the field anyway. In your example, if you don't even clear the username field, you should see 1Password replace the visible username with the one designated in the Login item when you ask 1Password to fill. When I get a moment I'll set up something using the example site you've kindly linked to but I will be very surprised if it doesn't behave as I expect it to.
0 -
I cleaned the name field by hand and left the password that Chrome autofill put their, I saw the extension place the name correctly but it did not overwrite the password.
0 -
Greetings @Stanzilla,
So far I've been unable to reproduce, the password is replaced for me which I confirm by viewing the contents of the field from the Chrome console. When 1Password overwrites a password field the only externally observable indicator will be the length of the password. If the password replaced is comparable in length to the password stored in the Login item there will be practically no visual cues to work off.
I have a couple of questions.
- Do you use the submit after filling feature in 1Password and is it enabled for this item?
- Does 1Password actually submit after filling when you test?
0 -
It did not autosubmit, I pressed submit manually.
0 -
-
Hi @Stanzilla,
Everything suggests that the password filled into the password field by Chrome matches the one stored in the Login item. To try and help highlight what I mean I've created two small recordings.
With this first one the password saved by Chrome is
peekaboo
and the one in 1Password ispeekab00
. So same length but two different characters.screen recording: different passwords
Notice around the 12 second mark how the password field changes and focus is left on the field. After that you can see the actual password has indeed changed when I view the value of the input field in the console on the right.
With the second recording I've altered the Login item so that the password is now
peekaboo
, matching what Chrome has stored.screen recording: same password
Around the 13 second mark you will notice how the password field doesn't change and focus is left on the username field. As the password field already contained the password 1Password was going to fill it ignores the field and 1Password will only leave focus on a field that it has filled. As 1Password didn't fill or leave focus on a password field it won't submit. For clarity I did have submit after filling disabled in both recordings, otherwise 1Password would have submitted after filling in the first.
If you're comfortable at all digging about in a page then on the TheTVDB sign-in page the command
document.getElementsByName("password")[0].value
will display the text contained in the password field so that you can view what is stored for comparison.If you're finding something isn't consistent with what I've written please do let me know.
0 -
@littlebobbytables Yes, so in my testing, the content of the password field does not change. See Removed by AgileBits
0 -
Greetings @Stanzilla,
So I'm a bit worried that you inadvertently displayed a real password. If that last recording did contain real data please do reset the password and delete the file so it is no longer accessible. I apologise for not making it clearer that I was only displaying deliberately fake credentials, my goto test password is almost always
peekaboo
.To me everything still points to that being the same password stored in the Login item. Are you sure the item stored in 1Password doesn't contain the same details?
What if you save an entirely new Login item for the same site, one that contains nonsense for the username and password, like my
somebody@example.com
/peekaboo
item. Are you observing that these aren't filled into the fields when you select the Login item?0 -
It was a real password but it's a dummy account so no worries. It starts to get a bit more mysterious here though, I checked which password is saved in chrome and there are actually two, a wrong one and a correct one. Then I checked 1Password and it also has two, the same wrong and correct ones.
userpass1
is the correct one,userpass2
is the wrong one. So for some reason, even though Chrome inserts the correct password into the field, and the value is the same after I had 1Password insert it, it still transmits the wrong one0 -
So I did what you asked and it gets even better: https://dl.dropboxusercontent.com/s/kwrprf449w35bty/2018-04-20_17-59-52.webm see what happens here? Chrome seems to replace the fields again after 1Password inserted them, probably using the wrong password from the Chrome db, resulting in wrong credentials.
0 -
Hi @Stanzilla,
Did Chrome indicate there was a page load at all? I suspect it might have. With the dummy Login item it filled both fields. As 1Password filled a password field it will attempt to submit the form. The attempt fails because they're dummy credentials and when the page loads again Chrome's autofill kicks in.
I suspect that if you temporarily disable submit after filling and then repeat the step that the two fields will fill and focus will be left on the password page. If you were to then manually submit you would see the failed attempt and the fields return to those being filled by Chrome.
0 -
@littlebobbytables You are correct, I don't like submit after filling anyway so I turned it off for now.
0 -
Me too. Glad that helped! :) :+1:
We always recommend disabling browser autofill both for usability and security reasons. Cheers!
0