Password input autocomplete="new-password" workaround?

I’ve noticed that the default password field in Bubble renders in HTML with the attribute autocomplete="new-password", even if the password field is in a login (not signup) context. The effect is that my password manager is always suggests generating a new password in that field instead of filling in with the already-saved password (saved username populates just fine). How are people working around this, or is it something the Bubble team can change?

I see someone worked around it by changing default signup/login priorities, but is there a more robust solution to this?

Log In Asks to Create a New Stong Password - Question - Bubble Forum

3 Likes

Hey @mike17 :wave:

Welcome to the Bubble community!

I have noticed it too. Maybe we can file a bug report with bubble and see if they can do anything about it. I’m not sure if we have any control over it.

I would also be curious to see if anyone has an actual workaround for this. :blush:

It might be some code that needs to be added. :man_shrugging:t2:

@j805 www.NoCodeMinute.com

For All Your No-Code Education Needs:

  • One-on-One Tutoring
  • eLearning Hub
  • Video Tutorials

Hello @mike17, @J805.

This happens because input passwords by default, as mentioned by you guys, have autocomplete="new-password" attribute.

So the browsers / passwords managers / extensions (…whatever…) Interpret that field it’s a sign-up one, and that’s why they suggest a new password even if the field it’s used for a login purposes.

Bubble could offer a dropdown in the input properties with election type: (sign up field or login field) and changing the autocomplete type depending on the election.

As you can see here:

The "autocomplete" attribute has multiple possible choices. The one we’re looking for, would be: current-password. So autocomplete="current-password" ⇾ This attribute value will indicate to the browser (or whatever we are using as password manager), that field is a password field that doesn’t need any “new password” suggestion.

Workaround:

This should be pretty easy, we just need to overwrite the "autocomplete" attribute for the specific field using JS.

E.g:

Result:

(In the left input the browser suggest a strong (new) password, while in the right it only suggests saved passwords).

Demo: Bubble | No-code apps
Editor: Anti-dup | Bubble Editor

@J805 I don’t think this could be “listed as bug”, but looks a good feature to submit in the Ideaboard

Redu.

6 Likes

That makes sense. Yes, great idea for the idea board. Especially since you already know the code for it.

I will definitely be adding this piece of code to my workflow. Thanks! :blush:

I got this solution working, too. Thanks!

In my case, either because the field was in a reusable or because of some conditional logic, Page is loaded didn’t work for me, but I triggered it on a state change, and added a 200ms delay before the javascript to make sure the element was there to find. (The 200ms delay ultimately fixed it, so this might work on page load, too).

If it was in a reusable element you could run the JavaScript when the “popup” comes visible the first time.

However the page loaded condition it’s just an example for demo purpose. You could run lately the JS at your election :v:

1 Like

I just made this update to my site. What a relief to finally have this fixed. Thanks again @yusaney1 for that bit of code we can add. I will definitely be saving this for future use. :blush:

2 Likes

The input needs to be visible when running the Javascript (I use this a lot in my app haha) so I create workflows → when “input…” is visible → Run javascript… It works pretty well

4 Likes

That makes sense. I had that intuition along the way, and then came up with various ways to make sure it would be visible before the javascript runs without JUST CHECKING TO SEE IF IT’S VISIBLE, like you recommend here. :man_facepalming:. Thanks!

1 Like

No id in my password input. I adapted the fix as below
document.querySelector(“input[type=‘password’]”).setAttribute(“autocomplete”,“current-password”);

1 Like

Thank you!

Honestly, it would be so nice if there were a setting for inputs of type password that asks what the password input is being used for:

  1. Setting a new password (autocomplete=“new-password”)
  2. Using an existing account password ( autocomplete=“current-password”)

My browser (Opera, which is Chromium-based) thinks the email/password fields are an address form and isn’t recognizing it’s a login form, so it would be awesome if email fields had some kind of way to designate what it’s being used for to improve browser behavior and UX.