Auto sign-in after auto-fill "clicks" wrong button

daelmaak

Take Slido's login page. The login form contains 2 buttons - "Forgot password?" and "Log in", in this order. The former has type="button" whereas the latter is type="submit", but the 1password's automatic sign-in feature interacts with the former and instead of login leads me to password reset.

This is not only wrong, but it's confusing as well as it might seem like the site's policy and user is therefore forced to reset her password for the wrong reason.

---

1Password Version: 8.10.33
Extension Version: 2.25.1
OS Version: Windows 11 23H2
Browser: Brave

EnerJi

Just experienced the same thing. I was very confused when a site I was on (different site) started taking me through the "new user flow" even though I've been registered for years.

david.m_1P

Hi @daelmaak and @EnerJi, thank you both for reaching out!

I'm sorry that you're experiencing trouble when filling on the Slido website. I've taken a look and was able to reproduce this behaviour on the Slido website. I've reported this to our development team for further investigation and have shared your experiences. I apologize for any inconvenience. While I'm unable to provide an exact timeline for a fix, once there is one, it will be listed in our release notes.

As a workaround in the meantime, you can disable the auto-submit feature in the 1Password extension's settings using the following steps:

1. Right-click the 1Password icon in your browser's toolbar, then select "Settings".
2. Click Autofill & save in the side panel.
3. Toggle off the "Sign in automatically after autofill" setting.

If you'd prefer to continue using the auto-submit feature, then I'd suggest using the drag and drop method or copy and paste to fill your credentials on this page.

Let me know if there's anything else I can help you with!

-David

ref: dev/core/core#30893

robinechometer

Same here, the login form of the software my company is developing is also being auto-submitted incorrectly by 1Password, hitting the button to send the user a login link rather than just logging them in with the auto-filled password. There doesn't seem to be anything we can do on our end to fix that behavior (short of reordering the buttons, which is not a reasonable solution here).

Would appreciate a fix for this on behalf of our users!
(In case you'd wanna test / reproduce with our login form, it can be found here: https://my.echometerapp.com/login )

david.m_1P

Hi @robinechometer, thanks for reaching out!

I've checked out the behaviour on the Echometer app website and experienced exactly what you've described. I apologize for any inconvenience. I've reported this issue to our development team to see if any improvements can be made to how the 1Password extension's auto-submit feature handles things here. In the meantime, the workaround described in the post above here should help to avoid this behaviour.

Let me know if there's anything else I can help you with.

-David

ref: dev/core/core#30943

ross_simpson

Another vote for this issue; we're seeing the same behavior across a number of our sites. Selecting a 1Password entry from the dropdown added by the 1P extension fills the form, but instead of submitting the form (by triggering a button with type=submit), a "link" (a button with type=button) is triggered which switches from the sign in flow to the create account flow.

URL: https://themeforest.net/ (click "Sign In" at the top right)

• Happens with:
  Browser: Firefox 127.0.2 (64-bit)
  Extension: 2.25.1

• Also happens with:
  Brave Version 1.67.123 Chromium: 126.0.6478.126 (Official Build) (arm64)
  Extension: 2.25.1

• Also happens with:
  Chrome Version 126.0.6478.127 (Official Build) (arm64)
  Extension: 2.25.1

  Note: the above Chrome profile was originally slightly out of date and was using extension version 2.23.1, which did NOT exhibit this problem! It was auto-updated to 2.25.1 and the problem then started happening.

I'm aware of the work-arounds above, however that won't help our users out in the world :)

@david.m_1P would you be able to provide an update once one is available from the dev team?

Thank you!

david.m_1P

Hi @ross_simpson, thanks for reaching out!

I was able to reproduce the same behaviour when visiting the ThemeForest webpage. I've reported this to our development team to see if any improvements can be made in how auto-submit is being handled here and I've left a note that you'd like to receive an update as well. I apologize for any inconvenience.

Let me know if I can help you with anything else!

-David

ref: dev/core/core#30966

tsdorsey

I understand the desire to make things simpler for users of 1Password. However, there are legitimate reasons for a website to have "buttons" inside of login and registration forms. Forgot password as a button (rather than an html anchor element) is valid using todays modern UI frameworks. Additional buttons might include "reveal password" or "create account". It doesn't always make sense to make these links.

I understand that if the website developer creates a login form with multiple buttons that are all type="button" then 1Password has very little information to go on and clicking the first one is a legitimate choice. However, what we have witnessed is that when the first button is marked as a simple type="button" and the second one is type="submit" the first one is still clicked by 1Password.

Some amount of effort to pick the correct button must be made by the 1Password extension. Forms having a button with a type="submit" has been standard for decades now. There is no excuse for 1Password to simply ignore this and blindly click the first button it finds.

carson63000

Unfortunately I think the only solution is to make auto sign-in a per-site setting, rather than a global setting. There are always going to be sites with weird login forms that 1Password gets wrong.

It's a shame to have to turn off a feature that is handy on 99% of sites because it makes the other 1% unusable, but that's the current situation for me, I'm afraid.

robinechometer

Yeah, I agree @tsdorsey . It's one thing that this kind of feature might have a couple edge cases where it won't work reliably, but the current implementation isn't even a best-effort approach. Preferring a type=submit button (if present) seems so obvious and simple to implement that it's surprising to me that the current implementation made it to general rollout. That alone would probably fix it for the vast majority of people are having an issue with this, even if for the rest a per-site setting would probably still be good to have.

Pleonasm

It may be worthwhile to consider moving the "Sign in automatically after autofill" setting into the 1Password app, and making that setting readable by the 1Password browser extension. In this way, the setting is maintained in the 1Password app and is persistent even when a user clears the browser's history.

ag_tommy

@Pleonasm @carson63000 @robinechometer et al.

You can disable auto-submit on a per site basis now with the latest version of 1Password in the browser. 2.26.1. Does that help?

You can now manage automatic sign-ins for individual items. While viewing an item in the extension, select the ellipsis button and choose “Don’t sign in automatically”.

robinechometer

Hey @ag_tommy , thanks for the update! It does help for any individual user, but fixing the underlying behavior to at the very least prefer "submit" buttons if they're present would be even better. Otherwise, our support will keep getting messages by users that don't know about this, and also it would just be nice to have this feature actually working on our login form, rather than having to disable it.

Also, at least for Firefox, the extension update seems to not have been rolled out yet, but I'll test once that's available

ag_tommy

You are correct. I show that 2.25.1 is the current available version for Firefox users. Hopefully, that will change in the coming days.

carson63000

Hi @ag_tommy , that's brilliant news, thanks!

I eagerly await the 2.26 release for Firefox!

ag_tommy

We hope it helps make things easier for you.