1Password submits wrong form when pressing return on Chrome

Options

We have a particular problem for one of our websites that upon hitting the return button after typing in a password, the 1Password extension for Chrome moves the focus to another form on the same page and submits that form.

The page contains a login form as well as a "password forgotten" form. Instead of submitting the login form, 1Password submits the "password forgotten" form. Here you can find the page:

https://www.europeers.de/extra/userdaten/

Just type "a" for Benutzername and "b" for "Passwort" and it jumps to "E-Mail" below and submits that form.

Deactivating JavaScript or the 1Password extension for Chrome solves the issue.

Any suggestions what to do and is it likely that the issue will be fixed in future versions? Thanks already!


1Password Version: 6.3.5
Extension Version: 4.6.2.90
OS Version: OS X 10.11.6
Sync Type: Dropbox

Comments

  • jxpx777
    jxpx777
    1Password Alumni
    edited November 2016
    Options

    Wow, @dword, that is a strange behavior indeed. I believe this is related to our autosave code and is related to the name attribute of the email form containing the text "password". I changed the name to remove this and it no longer happened. Can you see if that is also the case on your end? It also seems not to happen if I change the type of that field to email, so that might be a simple change you can make to remove the pain until we can improve things on our end.

    The reason for this is because some sites have fake password fields that only become password fields after you focus them or type in them. We look at text fields and see if they look like candidates for this based on several clues including the name attribute. We look for password-ish strings and if needed, we focus the field and trigger some key events. But, in this case, I see a couple of improvements we need to make:

    1. We should return focus to whichever field had it when autosave was triggered. We're not doing that right now and it's clearly screwing things up for you.
    2. We should adjust our string search to understand "forgot" as a hint that this is probably not a fake password field.
    3. Possibly we should limit our fake password field checking to the form that contains the element that triggered it. The reason I only say possibly is because we have seen quite a few sites that put each form field into its own <form> tag, so we would need some sort of heuristics in the extension to distinguish proper, well-coded forms like yours from the bizarro forms we see in other situations.

    I hope this helps! Let us know how you get on.

    --
    Jamie Phelps
    Code Wrangler @ AgileBits

    ref: OPX-1270

  • Dword
    Dword
    Community Member
    Options

    Hey,

    thanks a lot for the reply! For me, the quickfix with input type="email" works, so I'll stick to it for now. I'd be glad to find a general fix for the problem in future versions of the 1Password extension.

    Thanks a lot.

  • littlebobbytables
    littlebobbytables
    1Password Alumni
    Options

    Hopefully we'll see a beta with something for this soon :smile:

This discussion has been closed.