1PX autofilling (wrong) unchangeable field!
Hi!
I registered an new account on a website and saved all my credentials with 1PX. In that item in my 1P account the following credentials was stored under the Show Web Form Details section (see image).
removed by 1Password
When I tried to login in to my new login, 1PX always filled in the (first) user[email] field! In other words, the string Email was always printed as my username (witch is cleary wrong)!
So I tried to edit this, but in edit mode non of these field under the Show Web Form Details section was no where to be found, and thereforth not editable!!!
I tried to remove my username field and create a new one. But what ever I tried, the autofill always printed the string Email!!! Superweird!!!
To fix this I hade to create a new login item and copy paste the right credentials from the "broken" one to the new one! And lastly toss the "broken" one to the trash!
Is this a "one-hit-wonder" bugg or have someone else stumble across this?
Best regards
// Simon (^-^)
1Password Version: Not Provided
Extension Version: 1.12.1
OS Version: Not Provided
Sync Type: Not Provided
Comments
-
Hi @mrKnorring,
The ability to meaningfully edit the saved form details is a function really only possible with 1Password for Mac at the moment. I'm sure we'll improve on this as we go. What might work though is if you save an entirely new Login item on the sign-in page as that will hopefully allow 1Password X to do a better job of designating the correct field as the username.
Only if you're comfortable doing so of course but I would like to learn about the site where we get things wrong on the registration page as we can try and use that to improve future saving in the same scenario. Our support forum is public and posts are visible to the internet at large so it is only if you are happy to do so. Just because it revealed a bit more than what your visible username does I did remove the image as it had served its purpose. We can shift the conversation to email if you prefer as well.
0 -
Hi @littlebobbytables .
Sure I can share ;)
I did some debugging myself and I manage to recreate the problem :O
The site of focus here is a site called
https://solidsport.com/
(for english https://solidsport.com/play?locale=en)
where you can watch livestreams and videos of sport events in Sweden! In my case I use it to watch the top league of Badminton and Table Tennis. In order to watch a video you have to register an account. You can do in two ways
1. on the sign up page https://solidsport.com/sign_up (which work perfectly with 1PX :) )
2. by starting a video and do the signup in a popup window (it is here the problem occurs)!
If you start a video and are not logged in, the mediaplayer will show some button! One of these buttons is a login button. When you press any of these buttons a popup window will appear, which contains a login form. Since you don't have an account yet, you press the create account button in order to get to the sign up form.SO, if you try to save the sign up data with 1PX in this mode, the bugg will occur!!!
Hope you can follow my instructions :+1:
0 -
Hello @mrKnorring,
That's some great information and with it was able to reproduce the issue. While I don't know the precise details I do see partly where the confusion is coming from.
The registration page at https://solidsport.com/sign_up is a dedicated page and consists of little more than what you can see on the page. The saved Login item only records the expected fields within the saved from details section.
The modal registration/sign-in form has all the fields for both and its using CSS or similar to hide one set and display the other. So an item saved on this page records details for both the sign-in form and the registration form even though only one set is visible at the time of saving. Where it gets weird is in the filling stage. I see that 1Password X is basically restoring the email field to the state it was at the time of saving. As the field was hidden all that 1Password X recorded was the text
Emailand so it's filling that into the field. It doesn't restore the password field though, that it actually fills with the correct password. If I edit the item and replace the wordEmailin the right field with something else that's what 1Password fills. So the weird behaviour is that it appears to have come to two very different conclusions and I can't figure out how it decided this was the best course of action. Either restore both fields, which wouldn't be what you want or fill both fields with the designated username and password. There's definitely work to be done here and weird behaviour to understand. I shall file a report based on what I've been able to reproduce.ref: xplatform/brain#25
0 -
@littlebobbytables thx for the investigation :)
0 -
and thank you @mrKnorring for letting us know :smile: even with all the testing that gets done by the team here with so many sites in existence we do rely on our users letting us know when they find 1Password isn't working as well as it should.
0
