Browser extension fails when name attribute contains both username and password substring
Hi,
I have a login form which works perfectly as long as 1pw is not enabled. When I enable it, it still works when hitting the submit button, but submit on pressing enter fails. What happens is that the 1pw dialog pops up (when I didn't store the PW yet) and then nothing. The form is just not submitted. After a lot of trial and error, removing JS, CSS and almost all markup from the form I found out that the problem is the "name" attribute of the username field in the form. When I gradually reduce the length it starts working as soon as it is shorter than 41 characters.
So this will not work:<input type="text" id="username" name="verylongusernamefieldfortestingonepassword" />
but this will:<input type="text" id="username" name="verylongusernamefieldfortestingonepasswor" />
I have no idea how to see the JS for the helper then I would check myself but I would appreciate if someone could check this and see if that can be fixed.
Note that I use the 4.4.1.1 beta chrome extension, same happened with the stable version I had before.
1Password Version: 5.3.2
Extension Version: 4.4.1.1 (beta)
OS Version: OS X 10.10.4
Sync Type: Dropbox
Comments
-
Hi @Kitsunet,
I shall pass this directly to the devs. Now I don't know if they'll be around during the weekend but I will ensure they take a look.
0 -
Thanks! :) Enjoy the weekend.
0 -
Ok, I cannot edit the original post anymore but figured it is NOT the length of the field but the fact that it contains the word "password" in the name attribute. The above is true because in the "working" example the string "password" doesn't appear in the name anymore. So the length is irrelevant, what matters is that in my form the "username" field has a "name" attribute that contains both strings
username
ANDpassword
. This seems to be the breaking factor. I just tried a very simple form withname="username-password"
and that has the same defect. So probably a bit harder to fix but I still hope it's possible. Stepping through the collection of form elements it first seems fine and the two fields are picked up and get the right designation for username and password but something later happens that makes it fail for the username field.0 -
Hi, @Kitsunet! So sorry for the trouble you're having, but we greatly appreciate you bringing the issue to our attention. We haven't always had this great relationship we have with the web development community, so it's something we really value and don't take for granted. :)
Do you have a demo page that you can share for where this is happening? I'd love to take a look. Even something on JSBin or JSFiddle would be fine if you have the time to make a sample project.
If you can't share the code or a sample project, it would be helpful to know if this is happening with just a regular form submission or if you have some Javascript handlers in the mix. You said this was happening in the stable release before you updated to 4.4.1.1? That would be strange and hopefully orthogonal to 4.4.1.1, which was released specifically to address an issue where some of our Javascript was too quick and 1Password mini would steal focus before some key events could fire. If you are relying on some Javascript for your form processing, it could be that we have some more work to do on this front to avoid some other conflicts.
Thanks again for reporting this issue. I look forward to hearing how we can help improve the situation.
0 -
It's great that you care! Thanks. This is an OSS project, so everything visible:
Here is the login on our public demo: http://neos.demo.typo3.org/neos/login
And if you actually want to login, create a demo account here: http://neos.demo.typo3.org/en/try-me.htmlYou can see the wrong behaviour there, it features some JavaScript but to make clear that the JavaScript isn't the problem, see the following jsfiddle: https://jsfiddle.net/dqn1pkj5/
This is basically the markup of the form without JS or CSS. Still the same behaviour.
Now if you take this jsfiddle: http://jsfiddle.net/Lhqdpknf/3/
it works because I removed the[UsernamePassword]
parts from the field names (actually removing it from the username field is sufficient).As said, only happens if you use the
enter
key to submit the form, not when clicking the button.0 -
@Kitsunet I took at look at this tonight. I arrived at a solution, but it's one that I don't fully understand just yet, so I'm going to get some feedback on it before merging it in just in case there's something I am overlooking or a more obvious solution. We should have a new beta with a fix reasonably soon, but I don't have a firm timeframe to offer. I just wanted to post some feedback and let you know I didn't forget about you. :)
0 -
Hey, great to hear. Looking forward to the possible fix. Thanks a lot!
0 -
:+1: and of course thank you for bringing this to our attention and allowing us to improve the extension :smile:
0 -
Hey, as the current version of the browser extension still has this issue I would like to hear if I can hope for a solution? Our users would appreciate that and we cannot easily change the name of the username field for now. :)
0 -
@Kitsunet I'm sorry, but I'm not able to reproduce the issue with the latest version of the extension, but I think I might not have a good URL. I tried some of your links to the login screens but they were 404. I eventually found this page http://cms-next.demo.typo3.org/typo3/index.php?route=/login but it doesn't appear to have the
[UsernamePassword]
portion in the username field.0 -
Correct, sorry, URLs have chnaged in the mean time. We don't have a running demo right now, but if you have a bitnami account:
https://bitnami.com/stack/neosOtherwise give me a ping and I will see to get you setup with a demo site.
0 -
@Kitsunet I didn't have a Bitnami account, but I created one and am still not clear on how to view your demo. Probably user error… If you have a demo site, PM me here or email support@agilebits.com with a link to this thread and mentioning my full name and it'll get routed to me. Thanks!
--
Jamie Phelps
Code Wrangler @ AgileBits0