Google chrome autofilling all password inputs

Question

My Problem

I must have turned on google to autofill for a login on my site, however it is trying to now autofill that login data whenever I want to edit my account info or edit another users account info (as an admin). It fills in my data in weird spots. The issue seems to be that Chrome auto fills any input with a type of password and then whatever the input before it is (see image below). If I put a select box before it then it won't autofill.

I obviously don't want to have to go through and delete the password/phone every time I edit a user. I also don't want my users to have to do that when they are editing their own account. How do I remove it?

What I have tried (with no success)

• Adding autocomplete="off" to the form as well as both the phone and password inputs.
• Adding value="" to both inputs
• Changing the name= of the password input. I tried pw, pass, password, and cheese (incase chrome was picking up the name)
• Adding autocomplete="off" through the jquery .attr

What I have found

I found that Google may be intentionally ignoring autocomplete: Google ignoring autocomplete

I found another user posting a similar question but the solution is not working for me: Disable Chrome Autofill

I also found another user doing a work around involving creating a hidden password field which would take the google autocomplete, I'd prefer a cleaner solution as in my case I would also need a hidden input above it to avoid both from autofilling: Disable autofill in chrome without disabling autocomplete

Solution 1

In HTML5 with autocomplete attribute there is a new property called "new-password" which we can use to over come this issue. Following works for me.

<input id="userPassword" type="password" autocomplete="new-password">

current-password : Allow the browser or password manager to enter the current password for the site. This provides more information than "on" does, since it lets the browser or password manager know to use the currently-known password for the site in the field, rather than a new one.

new-password : Allow the browser or password manager to automatically enter the new password for the site. This might be automatically generated based on the other attributes of the control, or might simply tell the browser to present a "suggested new password" widget of some kind.

Refer: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password

Solution 2

This can be solved without hacks, but it is not necessarily intuitive. There are two weird decisions that Chrome makes. First, Chrome ignores autocomplete="off" in its parsing, and second, Chrome assumes the field that comes before a password field must be a username/email field, and should be autocompleted as such.

There are ways around this though that leverage the HTML5 autocomplete attribute spec.

As you will see in the link below, there are standard values for the attribute autocomplete. To avoid having Chrome assuming the field before a password is an email field, use either one of the official values (e.g., tel for a phone number), or make up a value that does not exist on the list, but is also not off or false.

Google suggests you use one of the standard values with new- prepended to the value, e.g., autocomplete="new-tel". If you want a password field to not autocomplete, you can use autocomplete="new-password", for instance.

While technically you could of course make the attribute something random without context to the same effect (e.g. autocomplete="blahblahblah"), I recommend the new- prefix as it helps give any future developer working on your code some context of what you're accomplishing with this attribute.

Ref: https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute

Solution 3

Sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.

Fix: browser autofill in by readonly-mode and set writable on focus

 <input type="password" readonly onfocus="this.removeAttribute('readonly');"/>

(focus = at mouse click and tabbing through fields)

Update: Mobile Safari sets cursor in the field, but does not show virtual keyboard. New Fix works like before but handles virtual keyboard:

<input id="email" readonly type="email" onfocus="if (this.hasAttribute('readonly')) {
    this.removeAttribute('readonly');
    // fix for mobile safari to show virtual keyboard
    this.blur();    this.focus();  }" />

Live Demo https://jsfiddle.net/danielsuess/n0scguv6/ // UpdateEnd

Explanation: Browser auto fills credentials to wrong text field?

@Samir: Chrome auto fills any input with a type of password and then whatever the input before it is

Sometimes I notice this strange behavior on Chrome and Safari, when there are password fields in the same form. I guess, the browser looks for a password field to insert your saved credentials. Then it autofills username into the nearest textlike-input field , that appears prior the password field in DOM (just guessing due to observation). As the browser is the last instance and you can not control it,

This readonly-fix above worked for me.

Solution 4

• fake inputs dont work
• autocomplete="off" / "new-password" / "false" and so on dont work, chrome ingores them all

Solution that worked for us:

<script>
        $(document).ready(function(){

            //put readonly attribute on all fields and mark those, that already readonly
            $.each($('input'), function(i, el){
                if ($(el).attr('readonly')) {
                    $(el).attr('shouldbereadonly', 'true');
                } else {
                    $(el).attr('readonly', 'readonly');
                }
            });

            //Remove unnecessary readonly attributes in timeout
            setTimeout(function(){

                $.each($('input'), function(i, el){
                    if (!$(el).attr('shouldbereadonly')) {
                        $(el).attr('readonly', null);
                    }
                });

            }, 500);
        });
    </script>

Solution 5

I would make a hidden password field instead of disabling auto-fill for chrome. Disabling auto-fill for you doesn't disable it for everyone.

So i got this.

<input type="hidden" name="Password" id="Password" value="Password" /><br />

(If you're just looking to disable it for yourself, Then disable it using chrome's settings.)

How to disable it with chromes settings:

Click the Chrome menu Chrome menu on the browser toolbar.
Select Settings.
Click Show advanced settings and find the "Passwords and forms" section.
Deselect the "Enable Autofill to fill out web forms in a single click" checkbox.

Credits go to heinkasner for that one.

Other than those two methods, I don't think this is possible to disable it for all users.

View more solutions

Comments

[Tyler]

Thanks for the reply, however this answer has already been suggested in other threads which I've linked to. My goal with this question was to attempt to find a clean solution and not a work-around.

[Juribiyan]

and don't forget to add input[readonly] { cursor: text; } to your CSS

[caniaskyouaquestion]

@dsuess This solution works, but it brakes soft keyboard triggering on mobile-safari. Keyboard pop-up is not triggered by onfocus when input field is readonly. So this is the only workaround but it comes with a cost, the one that i am trying to solve right now

[dsuess]

@caniaskyouaquestion Thanks for pointing this out. Check out the updated script.

[aruno]

Note: You unfortunately can't dynamically change autocomplete field. If your password field changes roles (maybe if a known user enters their email) then you should use two password fields - one of each type. [current Chrome as of today]

[Bartando]

This solution actually works. Unbelievable how something like autocomplete="off" doesn't work. When I am resetting password, I don't want to get the old password set into the field Google...

[Geoff Williams]

Urgh! This should be the accepted answer - I have a page where chrome keeps clobbering a user-supplied token (not a password) with the wrong value and adapting this was the only thing that worked - thanks man!

[d0rf47]

This is an excellent implementation thank you saved me many a hour of searching!