How to disable Chrome autofill (after 2020) - google-chrome

I've stumbled across this issue a couple of times in the last while, where Chrome ignores autocomplete="false" and autocomplete="off". It will now even ignore autocomplete="whatever" or anything you do to trick it, if someone has submitted a form with that random "hack" in it before.
In trying to solve this issue, I came across this StackOverflow question, which doesn't solve the problem if you've submitted a form containing this field before.
EDIT: This is NOT for password fields.

I had this issue with a field that has "number" in the name and this triggering the CreditCard Autocomplete Dialog. This solution helped me get rid of it.
Even though this is not the intended use of the option, I think this is unlikely to break and works without JavaScript Hacks. A one time code won't trigger an autocomplete so I treat the fields that are not supposed to autocomplete as one time codes.
<input type="text" name="number" autocomplete="one-time-code" />
This did the trick for me. I tested it in Chrome 87.0.4280.141 and it works fine.

autocomplete="new-password" and set placeholder attribute with some text works for me.
<input name="name1" placeholder="Nº" type="text" autocomplete="new-password" />

Everytime I found a solution Chrome throws a spanner in the works again.
No longer working
autocomplete="new-*"
add an offscreen positioned bogus input element style="position: fixed;top:-100px;left:-100px;" as first <form> element
set <form autocomplete="off">
use <textarea> and style it as a field
Working solution (15 jul 2021)
Append a dummy <input> without a name attribute and make the original <input> type="hidden"
HTML
<input type="hidden" name="myfield" class="no-autofill"> <input>
Note that any events, (click, blur, focus) that show your custom
autofill should be added to the visible <input> element.
Then add a change event to sync the value to the hidden input.
const fields = document.querySelectorAll('input.no-autofill');
for (const field of fields) {
const dummy = field.nextElementSibling;
dummy.addEventListener('change',e => {
field.value = e.target.value;
});
}
Ow, before implementing. Make sure you visit the Chromium bug tracker
and tell the Chrome Developers why following the standard is important. So one day we might be able to just use:
<input name="myfield" autocomplete="off">

its work in my local machine try it...
<input type="email" class="form-control" id="email" name="email" placeholder="Enter Email" readonly onfocus="this.removeAttribute('readonly');" style="background-color: white;">

It's November 2021, and none of the non-javascript solutions mentioned worked for my address-related field. What did work was actually changing the text in the label.
The Autocomplete dialog in Chrome was shown if:
The word "Address" is in the label at the start or end; and
There are at least two other address fields (seemingly anywhere in the page)
EDIT: If you put a zero-width joiner character entity in the middle of the word 'Address' in the label, the autocomplete dialog is suppressed!
i.e. set the label to Addres‍s
html, body {
font-family: 'Helvetica', Sans-Serif;
font-weight: 200;
line-height: 1.5em;
padding: 1em;
}
<div class="addressDiv">
<div>
<label>Focus on this field...Address</label>
<div>
<input autocomplete="off" type="text" aria-autocomplete="none" autocapitalize="none" />
</div>
</div>
<div>
<label>State</label>
<div>
<input autocomplete="address-level1" type="text" value="">
</div>
</div>
<div>
<label>City</label>
<div>
<input autocomplete="address-level2" type="text" value="">
</div>
</div>
</div>
<p>
See this JSFiddle
</p>

Read the note at the bottom before using this method
After struggling for a long time, I made it work reliably this way:
It is important that your input type is 'text'!!
define a css class
input.hidden-password {
-webkit-text-security: disc;
}
Then in your form, set autocomplete off, input types = 'text' and add the class to the input.
<form autocomplete="off">
<input
type = "text" // <----This is important
class = "hidden-password"
/>
</form>
C'mon Google, let us take control over our inputs! My client requires passwords to be changed very often and auto fill IS A BIG NO NO!
IMPORTANT NOTE Do not use this for login or any other place where security is required. I used this for a form within my app where the user was already authenticated and security was not required.

For Me, the problem only occurs, if I have multiple fields with the same value for autocomplete. If I set the value to a random number (Math.random()), no autocomplete is happening. I think it would also be possible to use an otherwise unique string.

To prevent 'manage addresses' level of of chrome popup: autocomplete='chrome-off'
To prevent autosuggest popup, if you can swing it: EXCLUDE name and id attributes.

Try to make your input readonly, enable it after focus
<input readonly="readonly" onfocus="this.removeAttribute('readonly');" type="text" value="test">

here is JS solution that works at this point in time for me:
<input name="name" type="text"
onfocus="this.__name = this.getAttribute('name'); this.removeAttribute('name')"
onblur="this.setAttribute('name',this.__name)"
>
The above js code stores input name to this.__name and removes the name onfocus later onblur name is restored so forms can work as expected, but chrome does not autofill.

No known attribute value is working in form tag. I have tried them all: do-not-show-ac, chrome-off, new-password, off...
The only way i found is by adding autocomplete='new-password' to every input component. To do it globaly, i am using this jquery:
<script>
$('input').attr('autocomplete', 'new-password');
</script>

The best way is to use JavaScript to skip browser's behavior, disableautofill.js does this.
You can try https://github.com/terrylinooo/disableautofill.js
<script src="https://cdn.jsdelivr.net/npm/disableautofill#2.0.0/dist/disableautofill.min.js"></script>
Usage:
var daf = new disableautofill({
'form': '#testForm', // Form id
'fields': [
'.test-pass', // password
'.test-pass2' // confirm password
],
'debug': true,
'callback': function() {
return checkForm(); // Form validator
}
});
daf.init();

How about just never submit the form? Nothing to remember!
Your app probably doesn't work without javascript anyway, right?
In fact, don't use a form at all, just collect the input values, serialize and do an ajax call.
$('#mybutton').on('click', function (e) {
$.ajax({
type: "POST",
url: 'mybackend',
data: $('#formdiv input').serialize(),
success: function (data) ...
Mind you, this is not a well tested idea, just something I have observed when I wanted autofill, and which I have not seen suggested in any of the many threads dealing with this issue.

I just resolved a related issue - it was forcing Chrome Autofill on an address field (Google Places Autocomplete, specifically) and no other solutions were working.
Eventually, we changed the nearest label to it from saying "Business Address" to being blank and set its text via CSS
#gmapsSearchLabel:after {
content: "Business Address";
}
And without a nearby label "saying" address, it stopped forcing Autofill.

A solution that works for me is to place a zero-width-white-space character into the placeholder text, so for example:
placeholder="Enter your address" becomes
placeholder="Enter your a[ZWSP]ddress"
Chrome is then unable to find "address" and skips autocomplete suggestions.
You can copy the character ( don't use the html entity etc. ) over at CSS Tricks. Here is the word "address" with the ZWSP character after the letter "a":
a​ddress

Dirty answer ,
edit "selectorForYourInputs" and works just fine, cross browser tested, max overhead 50ms, user never notice any performance lag:
counter = 0;
emptySearchboxInterval = setInterval(() => {
$(selectorForYourInputs).val("");
counter++;
counter == 100 ? clearInterval(emptySearchboxInterval) : null;
}, 20);

Related

Google chrome autofilling all password inputs

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
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
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
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.
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>
Following #Rob Porter feedback, in my case this was happening on a single input field (a PIN field), where password was being suggested and other field in the form was being populated.
Solved the issue by adding a dummy input field right before the PIN input as such:
<input id="pin-dummy" name="pin-dummy" type="text" style="opacity:0%;width:1px;height:1px;position:absolute;left:0px;top:0px" />
<input id="pin" name="pin" type="password" autocomplete="new-password" />
Chrome has updates, fake inputs are not working any more.
Chrome seems to remember everything after an success 200 net connection, whatever input[type=password] is activated on the screen will be remembered.
I've tried dynamically set the inputs to type text, clearing the contents, they don't always work, especially when there is a button to get verify code before submitting the form.
Finally, I figured it out:
listen to inputs focus and blur events,
everytime blur:
var psw1 = $('input[name=psw1]').val();
$('input[name=psw1]').val((new Array(psw1.length)).join('*'));
$('input[name=psw1]').attr('type', 'text');
everytime focus:
$('input[name=psw1]').attr('type', 'password');
$('input[name=psw1]').val(psw1)
the side effect is obvious, input's content would change every focus and blur event, but this method prevent chrome from remembering password perfectly.
Opacity
We fixed this by adding a field and setting its opacity to 0. so chrome still think there is a field an filling it.
width: 0px !important;
height: 0px !important;
opacity: 0 !important;
I noticed that Chrome / FF browser ALWAYS auto-filled the text input immediately preceding the password field. So the simplest solution was to add a "dummy" input:
I handle this problem with some simple js
<input type="password" name="password" class="autocomplete-off" readonly="readonly">
// autocomplete
$('input.autocomplete-off').click(function () {
$(this).removeAttr('readonly');
});
On my side the situation have been resolve by surronding my input with a form autocomplete="off".
<form autocomplete="off">
<input placeholder="Ville" type="text" class="w3-input town-input" type="text" />
</form>
Working fine !!!!

Disabling Safari autofill on usernames and passwords

You might already know, that Safari has a nasty autofill bug where it fills email, username and password fields no matter if you set autocomplete="off" or not.
Here's a basic form:
<form action="/" method="post">
<p>
<label>E-mail</label>
<input type="text" name="email" value="" />
</p>
<p>
<label>Password</label>
<input type="password" name="password" value="" />
</p>
</form>
...Safari autofills those fields on page load like it should, job well done!
If you put autocomplete="off" to the fields and/or the form element, Safari still autofills those fields:
<form action="/" method="post" autocomplete="off">
<p>
<label>E-mail</label>
<input type="text" name="email" value="" autocomplete="off" />
</p>
<p>
<label>Password</label>
<input type="password" name="password" value="" autocomplete="off" />
</p>
</form>
Even this doesn't work:
<form action="/" method="post" autocomplete="off">
<p>
<label>E-mail</label>
<input type="text" name="secretfield1" value="" autocomplete="off"/>
</p>
<p>
<label>Password</label>
<input type="password" name="secretfield2" value="" autocomplete="off" />
</p>
</form>
...since Safari looks up those <label> elements if they contain words "E-mail", "Password" etc. and goes ahead with the autofill.
Aaaahhhhha!, I thought, and tried this:
<form action="/" method="post" autocomplete="off">
<p>
<label>%REPLACE_EMAIL_TITLE%</label>
<input type="text" name="%REPLACE_EMAIL_NAME%" value="" autocomplete="off"/>
</p>
<p>
<label>%REPLACE_PASSWORD_TITLE%</label>
<input type="password" name="%REPLACE_PASSWORD_NAME%" value="" autocomplete="off" />
</p>
</form>
...and replace %TAGS% with the real names using JavaScript. Safari autofill kicks in. No matter if you set a 10 second timeout on the replacement.
So, is this really the only option?
<form action="/" method="post" autocomplete="off">
<p>
<label>That electronic postal address we all use, but can't write the title here because Safari fills this with YOUR information if you have autofill turned on</label>
<input type="text" name="someelectronicpostaladdress" value="" autocomplete="off"/>
</p>
<p>
<label>A set of characters, letters, numbers and special characters that is so secret that only you or the user you are changing it for knows, but can't write the title here because Safari sucks</label>
<input type="password" name="setofseeecretcharacters" value="" autocomplete="off" />
</p>
</form>
I hope not?
UPDATE: #skithund pointed out in Twitter, that Safari is getting a 4.0.3 update, which mentions "Login AutoFill". Does anyone know if that update is going to fix this?
The reason browsers are ignoring autocomplete=off is because there have been some web-sites that tried to disable auto-completing of passwords.
That is wrong.
And in July 2014 Firefox was the last major browser to finally implement the change to ignore any web-site that tries to turn off autocompleting of passwords.
June 2009: IEInternals blog where they discuss keeping the user in control (archive)
February 2014: Chrome's announcement when they began ignoring autocomplete=off (archive)
January 2014: Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager (archive)
Reddit discussion (archive)
One of the top user-complaints about our HTML Forms AutoComplete feature is “It doesn’t work– I don’t see any of my previously entered text.” When debugging such cases, we usually find that the site has explicitly disabled the feature using the provided attribute, but of course, users have no idea that the site has done so and simply assume that IE is buggy. In my experience, when features are hidden or replaced, users will usually blame the browser, not the website.
Any attempt by any web-site to circumvent the browser's preference is wrong, that is why browsers ignore it. There is no reason known why a web-site should try to disable saving of passwords.
Chrome ignores it
Safari ignores it
IE ignores it
Firefox ignores it
At this point, web developers typically protest “But I wouldn’t do this everywhere– only in a few little bits where it makes sense!” Even if that’s true, unfortunately, this is yet another case where there’s really no way for the browser to tell the difference. Remember, popup windows were once a happy, useful part of the web browsing experience, until their abuse by advertisers made them the bane of users everywhere. Inevitably, all browsers began blocking popups, breaking even the “good” sites that used popups with good taste and discretion.
What if I'm a special snowflake?
There are people who bring up a good use-case:
I have a shared, public area, kiosk style computer. We don't want someone to (accidentally or intentionally) save their password so the next user could use it.
That does not violate the statement:
Any attempt by any web-site to circumvent the browser's preference is wrong
That is because in the case of a shared kiosk:
it is not the web-server that has the oddball policy
it is the client user-agent that has the oddball policy
The browser (the shared computer) is the one that has the requirement that it not try to save passwords.
The correct way to prevent the browser from saving passwords
is to configure the browser to not save passwords.
Since you have locked down and control this kiosk computer: you control the settings. That includes the option of saving passwords.
In Chrome and Internet Explorer, you configure those options using Group Policies (e.g. registry keys).
From the Chrome Policy List:
AutoFillEnabled
Enable AutoFill
Data type: Boolean (REG_DWORD)
Windows registry location: Software\Policies\Chromium\AutoFillEnabled
Description: Enables Chromium's AutoFill feature and allows users to auto complete web forms using previously stored information such as address or credit card information. If you disable this setting, AutoFill will be inaccessible to users. If you enable this setting or do not set a value, AutoFill will remain under the control of the user. This will allow them to configure AutoFill profiles and to switch AutoFill on or off at their own discretion.
Please pass the word up to corporate managers that trying to disable autocompleting of password is wrong. It is so wrong that browsers are intentionally ignoring anyone who tries to do it. Those people should stop doing the wrong thing.™
Put it another way
In other words:
if the users browser
mistakes "Please enter the name of your favorite maiden name's first color." for a new password
and the user
doesn't want their browser
to update their password,
then they
will click Nope
if i want to save my HIPPA password: that's my right
if i want to save my PCI password: that's my right
if i want to save the "new password for the user": that's my right
if i want to save the one-time-password: that's my right
if i want to save my "first color's favorite maiden" answer: that's my right.
It's not your job to over-rule the user's wishes. It's their browser; not yours.
I had the same problem. And though my solution is not perfect, it seems to work. Basically, Safari seems to look for an input field with password and username and always tries to fill it. So, my solution was to add a fake username and password field before the current one which Safari could fill. I tried using style="display: none;" but that did not work. So, eventually, I just used
<input id="fake_user_name" name="fake_user[name]" tabindex="-1"
style="display:none;" type="text" value="Safari Autofill Me"
and this hid the input field out of sight and seemed to work fine.
I did not want to use JavaScript but I guess you could hide it with JavaScript.
Now Safari never autocompletes my username and password fields.
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?
Ok, you just noticed that:
Safari autofill kicks in. No matter [what the fields are named] #Jari
and there's an assumption that:
Safari seems to look for an input field with password and username and always tries to fill it #user3172174
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,
sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.
This readonly-fix above worked for me.
Adding the CSS to the input will hide the Safari button pseudo-element and users will not be able to use autocomplete:
input::-webkit-contacts-auto-fill-button,
input::-webkit-credentials-auto-fill-button {
visibility: hidden;
position: absolute;
right: 0;
}
This question has already been successfully answered, but as of today's date, the solution didn't work for me without making some oddly particular changes - so I'm noting it here as much for my own reference if I decide to come back to it as for everyone else's.
The fake input needs to be after the real email input in the dom.
The fake input requires a fake label.
The fake label cannot be absolutely positioned.
Can't use display, visibility or opacity to hide the fake elements.
The only solution I found was to clip the visibility of the fake elements with overflow: hidden.
<label for="user_email">Email</label>
<input autocomplete="off" type="text" value="user#email.com" name="user[email]" id="user_email">
<!-- Safari looks for email inputs and overwrites the existing value with the user's personal email. This hack catches the autofill in a hidden input. -->
<label for="fake_email" aria-hidden="true" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)">Email</label>
<input type="text" name="fake[email]" id="fake_email" style="height: 1px; width: 1px; overflow: hidden; clip: rect(1px, 1px, 1px, 1px)" tab-index="-1" aria-hidden="true">
For the record, the particular case this hack came in useful for was one where an admin is editing the profile of other users and Safari was replacing the email of the user with the email of the admin. We've decided that for the small (but frustrating) amount of support requests that this Safari 'feature' creates, it's not worth maintaining a hack that seems to need to evolve as Safari tightens up on it, and instead provide support to those users on how to turn off autofill.
Just put search into the name, Safari will ignore the field for autofill.
<input type="password" name="notsearch_password">
After scanning through Apple's Safari HTML pages and not finding anything on auto complete, I did some searching and thinking.
After reading a (mildly) related question on Apple discussions, I remembered that the default is to not allow remembered passwords, etc (which can be enabled in iDevice system settings, or at the prompt). Since Apple has moved this feature out of the browser and into their (proprietary, i)OS (screen shots on this article), I believe they are ignoring the HTML form/field property entirely.
Unless they change their mentality as to this feature, as I'm sure this is their expected behavior, on their locked down devices, I would work under the assumption that this isn't going away. This is probably different for native iOS apps. Definitely keep the form autocomplete="off" and hopefully they'll one day get back to the HTML5 standard for the feature.
I know this doesn't include any work around, but I think if you come to terms with it being a non-browser 'feature' on iDevices, it makes sense (in an Apple kind of way).
I can't believe this is still an issue so long after it's been reported. The above solutions didn't work for me, as safari seemed to know when the element was not displayed or off-screen, however the following did work for me:
<div style="position:absolute;height:0px; overflow:hidden; ">
Username <input type="text" name="fake_safari_username" >
Password <input type="password" name="fake_safari_password">
</div>
Hope that's useful for somebody!
I have also been bitten by Safari's weird default autocomplete behaviour, but rather than completely disable it, I managed to make it work for me by following the guidelines at https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands.
Specifically, I put autocomplete="username" on the username field and autocomplete="password-current" on the password field. This tells the browser which fields to autofill, rather than having it guess, and it fixed autocomplete for my use case.
This approach works for both "email first" login forms (password field not immediately visible, eg Google login) as well as conventional login forms with both username and password fields visible.
My issue: I have a section in an admin area that allows users to set all language values, some of which contain the words "password", "email", "email address" etc. I don't want these values to be filled with the user's details, they are for creating translations into another language. This is then a valid exception to the "circumvent the browser's preference" mentioned.
My solution: I simply created alternate names:
$name = str_replace('email','em___l',$name);
$name = str_replace('password','pa___d',$name);
<input type="text" name="<?=$name?>" id="<?=$name?>" />
Then when the form is posted:
foreach($_POST as $name=>$value) {
$name=str_replace('em___l','email',$name);
$name=str_replace('pa___d','password',$name);
$_POST[$name]=$value;
}
This is the only method that worked for me.
For me, this problem was very sharp. But only about password autofill.
Safari generates it's 'strong' password into a sign-in form. Not a sign-up form. Only the user's password will work in sign-in form, not generated. Obvious.
I made a few tries to disable it with advice from here. But without results.
BTW. It was easy to fix with angular binding. So. This code will work 4 you only in case of using Angular2+ in the web layer.
<mat-form-field appearance="fill">
<mat-label>Enter your password</mat-label>
<input #pwd
matInput
[type]="pwd.value.length === 0 ? 'text': 'password'"
formControlName="passwordCtrl"
required>
</mat-form-field>
Attribute [type] use one side binding with "[", "]". And automatically set value by the condition "(condition) ? option1: option2". If no symbols in the input - then the type is 'text'.
And not very 'clever' Safari browser doesn't perform autofill. So. Goal reached. Autofill disabled.
After more than 1 symbol in the input field. Type changes to 'password' very fast. And the user has no idea about something that happened. The type of the field is 'password'.
Also, it works with (keypressed) Event. Or using [(ngModel)]="pwd" instead of #pwd. And access by reactive forms.
But the basic thing that solved the problem for my cases - angular binding.
I came up with a similar solution to Nikita Danilov's, but for vanilla JavaScript instead of Angular.
Basic principle is for the field to start off as a generic type like "text" or "number", then switch to "password" or "email" where appropriate. onkeydown is a good event to bind here - should work on Desktop and Mobile.
Example:
<input
type="text"
name="password"
id="password"
autocomplete="off"
onkeydown="this.setAttribute('type','password')"
>
While I understand the points made against introducing this behaviour, I think many make an assumption that the context of a password field is always a login / registration form that the end-user interacts with. In some cases e.g. where passwords or other details are being set on admin panels, by users other than the end-user, I believe it is justified to avoid engaging the browser's autofill, as it is linked against the current user's personal data. In such case the current user, is not the end-user.
You can try this variant. It works for me.
If you change field value once, Safari will change it again. If user clicked at this field, after this the value wouldn't be changed by Safari automatically.
$.browser.chrome = /chrome/.test(navigator.userAgent.toLowerCase());
if($.browser.chrome){
$.browser.safari = false;
}
var isChanged=false;
$('#Email').change(function () {
if ($.browser.safari && !isChanged) {
$('#Email').val('#Model.Email');
}
});
$('#Email').click(function () {
if ( $.browser.safari && !isChanged) {
isChanged = true;
}
}); var isChangePassword = false;
$('#OldPassword').change(function () {
if ($.browser.safari && !isChangePassword) {
$('#OldPassword').val('');
}
});
$('#OldPassword').click(function () {
if ($.browser.safari && !isChangePassword) {
isChangePassword= true;
}
});
It seems the browser programmers think they know more than the website writers. While it's sometimes handy to allow the user to save passwords, there are other times when it's a security risk. For those times, this workaround might help:
Start by using a conventional text input, instead of a 'password' type.
Password: &nbsp <input type="text" id="fkpass" name="bxpass" class="tinp" size="20" />
Then - if you wish - set the focus to the input field.
<BODY onLoad="fitform()">
Put the JS at the end of the page.
<script type="text/javascript">
document.entry.fkpass.focus();
function fitform() {
document.getElementById('fkpass').autocomplete = 'off';
}
</script>
Now you have a conventional form field. What good is that?
Change the CSS style for that input so it uses a font that is all 'bullets' instead of characters.
<style type="text/css">
#font-face { font-family: fdot; src: url('images/dot5.ttf'); }
#font-face { font-family: idot; src: url('images/dot5.eot'); }
#font-face { font-family: wdot; src: url('images/dot5.woff'); }
#font-face { font-family: w2dot; src: url('images/dot5.woff2'); }
.tinp { font-family: fdot, idot, wdot, w2dot; color: #000; font-size:18px; }
</style>
Yes, you could 'tidy up' the code, and add .svg to it.
Either way, the end result is indistinguishable from the 'real' password input, and the browser won't offer to save it.
If you want the font, it's here.
It was created with CorelDraw and converted with an online webfont conversion utility. (dot_webfont_kit.zip 19.3k)
I hope this helps.
Remove <form> element. To keep form behavior you can listen keypress event for input fields to handle enter key pressed. Just in case I removed input type="submit" too. You can use button type="button".
Better than use JS to clear content - simply fake password field:
<input type="text" name="user" />
<input fake_pass type="password" style="display:none"/>
<input type="password" name="pass" />
A password type doubled put the browser in incertitude so it autocompletes only user name
fake_pass input should not have name attribute to keep $_POST clean!
The CSS display: none solutions mentioned here did not work for me (October 2016). I fixed this issue with JavaScript.
I don't mind the browser remembering passwords, but wanted to prevent a bad autofill. In my case, a form with a password field and no associated username field. (User edit form in Drupal 7 site, where the password field is required only for some operations.) Whatever I tried, Safari would find a victim field for the username of the autofilled password (the field placed visually before, for instance).
I'm restoring the original value as soon as Safari does the autofill. I'm trying this only for the first 2 seconds after page load. Probably even lower value is OK. My tests showed the autofill happens around 250 ms after page load (though I imagine this number depends a lot on how the page is constructed and loaded).
Here's my JavaScript code (with jQuery):
// Workaround for Safari autofill of the e-mail field with the username.
// Try every 50ms during 2s to reset the e-mail to its original value.
// Prevent this reset if user might have changed the e-mail himself, by
// detecting focus on the field.
if ($('#edit-mail').length) {
var element = $('#edit-mail');
var original = element.attr('value');
var interval = setInterval(function() {
if ($(document.activeElement).is(element)) {
stop();
} else if (element.val() != original) {
element.val(original);
stop();
}
}, 50);
var stop = function() {
clearTimeout(timeout);
clearInterval(interval);
}
var timeout = setTimeout(function() {
clearInterval(interval);
}, 2000);
}
I had the same problem suddenly in a SPA with React in Mobile Safari 10.3.1
I do not need any tricky workarounds before in all tested browsers, even Mobile Safari IOS 10.2
But since 10.3.1 username or password will be filled in fields mentioning the words 'password','email','username' in any forms after login with active remember option. It seems that the rendered DOM-Tree is 'analyzed' using a full text search and then the user agent fill in data without respecting any autocomplete="off" setting.
Happens funnyli also on placeholder text for a field. So you must be very carful with naming, when you don't want to have prefilled username or password in places where this data is not useful.
The only solution after hours of investigating was the solution here posted too.
Provide a input field named "email" and hideout the containing div with height: 0px, overflow: hidden.
You can disable it by adding this attribute to password input
autocomplete="new-password"

An invalid form control with name='' is not focusable

In Google Chrome some customers are not able to proceed to my payment page.
When trying to submit a form I get this error:
An invalid form control with name='' is not focusable.
This is from the JavaScript console.
I read that the problem could be due to hidden fields having the required attribute.
Now the problem is that we are using .net webforms required field validators, and not the html5 required attribute.
It seems random who gets this error.
Is there anyone who knows a solution for this?
This issue occurs on Chrome if a form field fails validation, but due to the respective invalid control not being focusable the browser's attempt to display the message "Please fill out this field" next to it fails as well.
A form control may not be focusable at the time validation is triggered for several reasons. The two scenarios described below are the most prominent causes:
The field is irrelevant according to the current context of the business logic. In such a scenario, the respective control should be disabled or removed from the DOM or not be marked with the required attribute at that point.
Premature validation may occur due to a user pressing ENTER key on an input. Or a user clicking on a button/input control in the form which has not defined the type attribute of the control correctly. If the type attribute of a button is not set to button, Chrome (or any other browser for that matter) performs a validation each time the button is clicked because submit is the default value of a button's type attribute.
To solve the problem, if you have a button on your page that does something else other than submit or reset, always remember to do this: <button type="button">.
Adding a novalidate attribute to the form will help:
<form name="myform" novalidate>
In your form, You might have hidden input having required attribute:
<input type="hidden" required />
<input type="file" required style="display: none;"/>
The form can't focus on those elements, you have to remove required from all hidden inputs, or implement a validation function in javascript to handle them if you really require a hidden input.
In case anyone else has this issue, I experienced the same thing. As discussed in the comments, it was due to the browser attempting to validate hidden fields. It was finding empty fields in the form and trying to focus on them, but because they were set to display:none;, it couldn't. Hence the error.
I was able to solve it by using something similar to this:
$("body").on("submit", ".myForm", function(evt) {
// Disable things that we don't want to validate.
$(["input:hidden, textarea:hidden, select:hidden"]).attr("disabled", true);
// If HTML5 Validation is available let it run. Otherwise prevent default.
if (this.el.checkValidity && !this.el.checkValidity()) {
// Re-enable things that we previously disabled.
$(["input:hidden, textarea:hidden, select:hidden"]).attr("disabled", false);
return true;
}
evt.preventDefault();
// Re-enable things that we previously disabled.
$(["input:hidden, textarea:hidden, select:hidden"]).attr("disabled", false);
// Whatever other form processing stuff goes here.
});
Also, this is possibly a duplicate of "Invalid form control" only in Google Chrome
In my case the problem was with the input type="radio" required being hidden with:
visibility: hidden;
This error message will also show if the required input type radio or checkbox has a display: none; CSS property.
If you want to create custom radio/checkbox inputs where they must be hidden from the UI and still keep the required attribute, you should instead use the:
opacity: 0; CSS property
None of the previous answers worked for me, and I don't have any hidden fields with the required attribute.
In my case, the problem was caused by having a <form> and then a <fieldset> as its first child, which holds the <input> with the required attribute. Removing the <fieldset> solved the problem. Or you can wrap your form with it; it is allowed by HTML5.
I'm on Windows 7 x64, Chrome version 43.0.2357.130 m.
Not only required field as mentioned in other answers. Its also caused by placing an <input> field in a hidden <div> which holds an invalid value.
Consider below example,
<div style="display:none;">
<input type="number" name="some" min="1" max="50" value="0">
</div>
This throws the same error. So make sure the <input> fields inside hidden <div> doesnt hold any invalid value.
This issue occurs when you provide style="display: none;" and required attribute to the input field, and there will be validation on submit.
for example:
<input type="text" name="name" id="name" style="display: none;" required>
This issue can be resolved by removing required attribute from the input field from your HTML. If you need to add required attribute, add it dynamically. If you are using JQuery, use below code:
$("input").prop('required',true);
If you need to remove this field dynamically,
$("input").prop('required',false);
You can also make use of plain Javascript if you are not using JQuery:
document.getElementById('element_id').removeAttribute('required');
Yet another possibility if you're getting the error on a checkbox input. If your checkboxes use custom CSS which hides the default and replaces it with some other styling, this will also trigger the not focusable error in Chrome on validation error.
I found this in my stylesheet:
input[type="checkbox"] {
visibility: hidden;
}
Simple fix was to replace it with this:
input[type="checkbox"] {
opacity: 0;
}
It can be that you have hidden (display: none) fields with the required attribute.
Please check all required fields are visible to the user :)
For me this happens, when there's a <select> field with pre-selected option with value of '':
<select name="foo" required="required">
<option value="" selected="selected">Select something</option>
<option value="bar">Bar</option>
<option value="baz">Baz</option>
</select>
Unfortunately it's the only cross-browser solution for a placeholder (How do I make a placeholder for a 'select' box?).
The issue comes up on Chrome 43.0.2357.124.
For Select2 Jquery problem
The problem is due to the HTML5 validation cannot focus a hidden invalid element.
I came across this issue when I was dealing with jQuery Select2 plugin.
Solution
You could inject an event listener on and 'invalid' event of every element of a form so that you can manipulate just before the HTML5 validate event.
$('form select').each(function(i){
this.addEventListener('invalid', function(e){
var _s2Id = 's2id_'+e.target.id; //s2 autosuggest html ul li element id
var _posS2 = $('#'+_s2Id).position();
//get the current position of respective select2
$('#'+_s2Id+' ul').addClass('_invalid'); //add this class with border:1px solid red;
//this will reposition the hidden select2 just behind the actual select2 autosuggest field with z-index = -1
$('#'+e.target.id).attr('style','display:block !important;position:absolute;z-index:-1;top:'+(_posS2.top-$('#'+_s2Id).outerHeight()-24)+'px;left:'+(_posS2.left-($('#'+_s2Id).width()/2))+'px;');
/*
//Adjust the left and top position accordingly
*/
//remove invalid class after 3 seconds
setTimeout(function(){
$('#'+_s2Id+' ul').removeClass('_invalid');
},3000);
return true;
}, false);
});
If you have any field with required attribute which is not visible during the form submission, this error will be thrown. You just remove the required attribute when your try to hide that field. You can add the required attribute in case if you want to show the field again. By this way, your validation will not be compromised and at the same time, the error will not be thrown.
It's weird how everyone is suggesting to remove the validation, while validation exists for a reason...
Anyways, here's what you can do if you're using a custom control, and want to maintain the validation:
1st step. Remove display none from the input, so the input becomes focusable
.input[required], .textarea[required] {
display: inline-block !important;
height: 0 !important;
padding: 0 !important;
border: 0 !important;
z-index: -1 !important;
position: absolute !important;
}
2nd step. Add invalid event handler on the input to for specific cases if the style isn't enough
inputEl.addEventListener('invalid', function(e){
//if it's valid, cancel the event
if(e.target.value) {
e.preventDefault();
}
});
It happens if you hide an input element which has a required attribute.
Instead of using display:none you can use opacity: 0;
I also had to use some CSS rules (like position:absolute) to position my element perfectly.
Yea.. If a hidden form control has required field then it shows this error. One solution would be to disable this form control. This is because usually if you are hiding a form control it is because you are not concerned with its value. So this form control name value pair wont be sent while submitting the form.
I came here to answer that I had triggered this issue myself based on NOT closing the </form> tag AND having multiple forms on the same page. The first form will extend to include seeking validation on form inputs from elsewhere. Because THOSE forms are hidden, they triggered the error.
so for instance:
<form method="POST" name='register' action="#handler">
<input type="email" name="email"/>
<input type="text" name="message" />
<input type="date" name="date" />
<form method="POST" name='register' action="#register">
<input type="text" name="userId" />
<input type="password" name="password" />
<input type="password" name="confirm" />
</form>
Triggers
An invalid form control with name='userId' is not focusable.
An invalid form control with name='password' is not focusable.
An invalid form control with name='confirm' is not focusable.
Another possible cause and not covered in all previous answers when you have a normal form with required fields and you submit the form then hide it directly after submission (with javascript) giving no time for validation functionality to work.
The validation functionality will try to focus on the required field and show the error validation message but the field has already been hidden, so "An invalid form control with name='' is not focusable." appears!
Edit:
To handle this case simply add the following condition inside your submit handler
submitHandler() {
const form = document.body.querySelector('#formId');
// Fix issue with html5 validation
if (form.checkValidity && !form.checkValidity()) {
return;
}
// Submit and hide form safely
}
Edit: Explanation
Supposing you're hiding the form on submission, this code guarantees that the form/fields will not be hidden until form become valid. So, if a field is not valid, the browser can focus on it with no problems as this field is still displayed.
There are many ways to fix this like
Add novalidate to your form but its totally wrong as it will remove form validation which will lead to wrong information entered by the users.
<form action="...." class="payment-details" method="post" novalidate>
Use can remove the required attribute from required fields which is also wrong as it will remove form validation once again.
Instead of this:
<input class="form-control" id="id_line1" maxlength="255" name="line1" placeholder="First line of address" type="text" required="required">
Use this:
<input class="form-control" id="id_line1" maxlength="255" name="line1" placeholder="First line of address" type="text">
Use can disable the required fields when you are not going to submit the form instead of doing some other option. This is the recommended solution in my opinion.
like:
<input class="form-control" id="id_line1" maxlength="255" name="line1" placeholder="First line of address" type="text" disabled="disabled">
or disable it through javascript / jquery code dependes upon your scenario.
It will show that message if you have code like this:
<form>
<div style="display: none;">
<input name="test" type="text" required/>
</div>
<input type="submit"/>
</form>
You may try .removeAttribute("required") for those elements which are hidden at the time of window load. as it is quite probable that the element in question is marked hidden due to javascript (tabbed forms)
e.g.
if(document.getElementById('hidden_field_choice_selector_parent_element'.value==true){
document.getElementById('hidden_field').removeAttribute("required");
}
This should do the task.
It worked for me... cheers
There are things that still surprises me... I have a form with dynamic behaviour for two different entities. One entity requires some fields that the other don't.
So, my JS code, depending on the entity, does something like:
$('#periodo').removeAttr('required');
$("#periodo-container").hide();
and when the user selects the other entity:
$("#periodo-container").show();
$('#periodo').prop('required', true);
But sometimes, when the form is submitted, the issue apppears: "An invalid form control with name=periodo'' is not focusable (i am using the same value for the id and name).
To fix this problem, you have to ensurance that the input where you are setting or removing 'required' is always visible.
So, what I did is:
$("#periodo-container").show(); //for making sure it is visible
$('#periodo').removeAttr('required');
$("#periodo-container").hide(); //then hide
Thats solved my problem... unbelievable.
In my case..
ng-show was being used.
ng-if was put in its place and fixed my error.
Wow, a lot of answers here!
If the problem is <input type="hidden" required="true" />, then you can solve this in just a few lines.
The logic is simple and straight-forward:
Mark every required input on page-load with a data-required class.
On submit, do two things: a) Add required="true" to all data-required inputs. b) Remove required="true"` from all hidden inputs.
HTML
<input type="submit" id="submit-button">
Pure JavaScript
document.querySelector('input,textarea,select').filter('[required]').classList.add('data-required');
document.querySelector('#submit-button').addEventListener('click', function(event) {
document.querySelector('.data-required').prop('required', true);
document.querySelector('input,textarea,select').filter('[required]:hidden').prop('required', false);
return true;
}
jQuery
$('input,textarea,select').filter('[required]').addClass('data-required');
$('#submit-button').on('click', function(event) {
$('.data-required').prop('required', true);
$('input,textarea,select').filter('[required]:hidden').prop('required', false);
return true;
}
For Angular use:
ng-required="boolean"
This will only apply the html5 'required' attribute if the value is true.
<input ng-model="myCtrl.item" ng-required="myCtrl.items > 0" />
I found same problem when using Angular JS. It was caused from using required together with ng-hide. When I clicked on the submit button while this element was hidden then it occurred the error An invalid form control with name='' is not focusable. finally!
For example of using ng-hide together with required:
<input type="text" ng-hide="for some condition" required something >
I solved it by replacing the required with ng-pattern instead.
For example of solution:
<input type="text" ng-hide="for some condition" ng-pattern="some thing" >
Not just only when specify required, I also got this issue when using min and max e.g.
<input type="number" min="1900" max="2090" />
That field can be hidden and shown based on other radio value. So, for temporary solution, I removed the validation.
I have seen this question asked often and have come across this 'error' myself. There have even been links to question whether this is an actual bug in Chrome.
This is the response that occurs when one or more form input type elements are hidden and these elements have a min/max limit (or some other validation limitation) imposed.
On creation of a form, there are no values attributed to the elements, later on the element values may be filled or remain unchanged.
At the time of submit, the form is parsed and any hidden elements that are outside of these validation limits will throw this 'error' into the console and the submit will fail. Since you can't access these elements (because they are hidden) this is the only response that is valid.
This isn't an actual fault nor bug. It is an indication that there are element values about to be submitted that are outside of the limits stipulated by one or more elements.
To fix this, assign a valid default value to any elements that are hidden in the form at any time before the form is submitted, then these 'errors' will never occur. It is not a bug as such, it is just forcing you into better programming habits.
NB: If you wish to set these values to something outside the validation limits then use form.addEventListener('submit', myFunction) to intercept the 'submit' event and fill in these elements in "myFunction". It seems the validation checking is performed before "myFunction() is called.
Its because there is a hidden input with required attribute in the form.
In my case, I had a select box and it is hidden by jquery tokenizer using inline style. If I dont select any token, browser throws the above error on form submission.
So, I fixed it using the below css technique :
select.download_tag{
display: block !important;//because otherwise, its throwing error An invalid form control with name='download_tag[0][]' is not focusable.
//So, instead set opacity
opacity: 0;
height: 0px;
}
For other AngularJS 1.x users out there, this error appeared because I was hiding a form control from displaying instead of removing it from the DOM entirely when I didn't need the control to be completed.
I fixed this by using ng-if instead of ng-show/ng-hide on the div containing the form control requiring validation.
Hope this helps you fellow edge case users.

Stop Google chrome auto fill the input [duplicate]

This question already has answers here:
Disabling Chrome Autofill
(68 answers)
Closed 5 years ago.
I have a input type text for user to change their email & password in account setting page.
How can stop Chrome auto fill the input.
Chrome remember the input data from log in page and it auto fill in account setting page.
Chrome auto fill the input change my email & password in account setting page
We are no longer dependent on hacks for this. You can set autocomplete to new-password and it will work as intended.
<input type="password" name="pwd" autocomplete="new-password">
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-autocomplete
Are you explicitly setting the values as blank? For example:
<input type="text" name="textfield" value="">
That should stop browsers putting data in where it shouldn't. Alternatively, you can add the autocomplete attribute to the form tag:
<form autocomplete="off" ...></form>
Solution 1:
Putting 2 lines of code under under <form ..> tag does the trick.
<form id="form1" runat="server" >
<input style="display:none" type="text" name="fakeusernameremembered"/>
<input style="display:none" type="password" name="fakepasswordremembered"/>
...
Read more
Solution 2: It removes "name" and "id" attributes from elements and assigns them back after 1ms. Put this in document get ready.
$('form[autocomplete="off"] input, input[autocomplete="off"]').each(function () {
var input = this;
var name = $(input).attr('name');
var id = $(input).attr('id');
$(input).removeAttr('name');
$(input).removeAttr('id');
setTimeout(function () {
$(input).attr('name', name);
$(input).attr('id', id);
}, 1);
});
Solution 3: Tested in Chrome 60.0.3112.101
<input type="password" name="pwd" autocomplete="new-password">
This issue still exists as of Version 55.0.2883.87 m. (on Windows 10)
Solutions like setting the autocomplete attribute on a form
or adding fake input fields and removing the name attribute before submit do not work anymore, since Chrome ignores or instantly auto-completes them on removal.
The only way to get it currently to work as intended is to set the autocomplete attribute to "new-password"
<input type="text" name="text" autocomplete="new-password">
even on non password type inputs.
The latest version of Chrome (46.0.2490.86) appears to have changed behaviour again. This time, AutoFill has nothing to do with autocomplete or readonly or other workarounds suggested here (and on these bug reports https://code.google.com/p/chromium/issues/detail?id=468153, https://bugs.chromium.org/p/chromium/issues/detail?id=587466)
Rather, AutoFill now looks at the label next to the input box and generates an AutoFill based on that (as well as the id and name). A big clue is how AutoFill can actually fill multiple fields at once (e.g. Street, Suburb and State). It appears to be using several techniques (label, name, id) to discern the spatial relationship between fields.
So a workaround is to insert junk text into the label inside a hidden span...
S<span style="display:none">_</span>uburb:
...and also obfuscate/remove the id and name. This was the only thing that prevented Suburb AutoFill for me.
Unfortunately autocomplete="off" didn't work for me (anymore). So here is my solution:
First read and then remove "name" and "id" attributes from elements. Then, after 1ms, set these attributes back again with values read before. For me it works :)
<form autocomplete="off"><br />
<input type="text" name="username" id="username" /><br />
<input type="password" name="password" id="password" /><br />
</form>
<pre>
$('form[autocomplete="off"] input, input[autocomplete="off"]').each(function(){
var input = this;
var name = $(input).attr('name');
var id = $(input).attr('id');
$(input).removeAttr('name');
$(input).removeAttr('id');
setTimeout(function(){
$(input).attr('name', name);
$(input).attr('id', id);
}, 1);
});
</pre>
By setting autocomplete="new-password" , it works.
Before testing, you clear browsing data first
Almost jumped out the window trying to solve this... seems Google now ignores Autocomplete ON and OFF. I had used on older fix (such as fake hidden password fields - which also no longer worked). Based on the living standard spec - you need to use an auto-fill tokens instead. You must use them in the appropriate use-case context. Hope this is helpful.
https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute
Chrome ignores both autocomplete="anything" and hidden fields. A HTML/CSS workaround would be using an absolute positioned password field before the real one:
<input type="text" name="username" required>
<input style="visibility: hidden; position: absolute; left:-99999px" type="password" name="fakepasswordfieldtoturnoffautocomplete">
<input type="password" name="password" required>
EDIT:
As referred in multiple other answers in other duplicate questions, the most elegant working solution so far is this:
<input type="password" readonly onfocus="this.removeAttribute('readonly');"/>
Try hidden password element
<form>
<input type="text" name="fakeusername" class="fake-autofill-fields"/>
<input type="password" name="fakepassword" class="fake-autofill-fields"/>
...
...
</form>
<script>
$(document).ready(function () {
$(".fake-autofill-fields").show();
window.setTimeout(function () {
$(".fake-autofill-fields").hide();
}, 1);
});
</script>
Enter a value of ' ' (a blank space) for the username field and Chrome doesn't autopopulate username or password.
<input type = 'text' value = ' ' name = 'username' />
If you're ever populating the username with a user-entered value, code to enter a ' ' if there's no user-entered value.
Try this:
<div id="form_container">
<input type="text" name="username" autocomplete="off">
<input type="password" name="pwd" autocomplete="off">
<input tytep="submit" name="login" id="login" value="Log In">
</div>`
The jquery code:
jQuery("#login").click(function(){
jQuery("#form_container").wrap('<form method="post"></form>');
jQuery("form").submit();
});
If you don't wrap your input fields into a form, then the chrome's autofill won't come up.
When you click on the submit button, just frap the fields around the form and fire a submit() on the form.
I had a similar problem. After all of the attempts failed. I tried this hack of setting
type = "search"
instead of text. Even though its not a pretty hack. It does not cause any issues in majority of cases. type search is no different than text as of now.
This works:
<form autocomplete="off" ...></form>
Tested on Chrome 56.0.2924.87 (64-bit)

Chrome ignores autocomplete="off"

I've created a web application which uses a tagbox drop down. This works great in all browsers except Chrome browser (Version 21.0.1180.89).
Despite both the input fields AND the form field having the autocomplete="off" attribute, Chrome insists on showing a drop down history of previous entries for the field, which is obliterating the tagbox list.
Prevent autocomplete of username (or email) and password:
<input type="email" name="email"><!-- Can be type="text" -->
<input type="password" name="password" autocomplete="new-password">
Prevent autocomplete a field (might not work):
<input type="text" name="field" autocomplete="nope">
Explanation:
autocomplete still works on an <input>despite having autocomplete="off", but you can change off to a random string, like nope.
Others "solutions" for disabling the autocomplete of a field (it's not the right way to do it, but it works):
1.
HTML:
<input type="password" id="some_id" autocomplete="new-password">
JS (onload):
(function() {
var some_id = document.getElementById('some_id');
some_id.type = 'text';
some_id.removeAttribute('autocomplete');
})();
or using jQuery:
$(document).ready(function() {
var some_id = $('#some_id');
some_id.prop('type', 'text');
some_id.removeAttr('autocomplete');
});
2.
HTML:
<form id="form"></form>
JS (onload):
(function() {
var input = document.createElement('INPUT');
input.type = 'text';
document.getElementById('form').appendChild(input);
})();
or using jQuery:
$(document).ready(function() {
$('<input>', {
type: 'text'
}).appendTo($('#form'));
});
To add more than one field using jQuery:
function addField(label) {
var div = $('<div>');
var input = $('<input>', {
type: 'text'
});
if(label) {
var label = $('<label>', {
text: label
});
label.append(input);
div.append(label);
} else {
div.append(input);
}
div.appendTo($('#form'));
}
$(document).ready(function() {
addField();
addField('Field 1: ');
});
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>
<form id="form"></form>
Works in:
Chrome: 49+
Firefox: 44+
UPDATE
It seems now Chrome ignores the style="display: none;" or style="visibility: hidden; attributes.
You can change it to something like:
<input style="opacity: 0;position: absolute;">
<input type="password" style="opacity: 0;position: absolute;">
In my experience, Chrome only autocompletes the first <input type="password"> and the previous <input>. So I've added:
<input style="display:none">
<input type="password" style="display:none">
To the top of the <form> and the case was resolved.
It appears that Chrome now ignores autocomplete="off" unless it is on the <form autocomplete="off"> tag.
2021 UPDATE:Change <input type="text"> to <input type="search" autocomplete="off" >
That is all. Keeping the below answer around for nostalgia.
For a reliable workaround, you can add this code to your layout page:
<div style="display: none;">
<input type="text" id="PreventChromeAutocomplete"
name="PreventChromeAutocomplete" autocomplete="address-level4" />
</div>
Chrome respects autocomplete=off only when there is at least one other input element in the form with any other autocomplete value.
This will not work with password fields--those are handled very differently in Chrome. See https://code.google.com/p/chromium/issues/detail?id=468153 for more details.
UPDATE: Bug closed as "Won't Fix" by Chromium Team March 11, 2016. See last comment in my originally filed bug report, for full explanation. TL;DR: use semantic autocomplete attributes such as autocomplete="new-street-address" to avoid Chrome performing autofill.
Modern Approach
Simply make your input readonly, and on focus, remove it. This is a very simple approach and browsers will not populate readonly inputs. Therefore, this method is accepted and will never be overwritten by future browser updates.
<input type="text" onfocus="this.removeAttribute('readonly');" readonly />
The next part is optional. Style your input accordingly so that it does not look like a readonly input.
input[readonly] {
cursor: text;
background-color: #fff;
}
WORKING EXAMPLE
Well, a little late to the party, but it seems that there is a bit of misunderstanding about how autocomplete should and shouldn't work. According to the HTML specifications, the user agent (in this case Chrome) can override autocomplete:
https://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute
A user agent may allow the user to override an element's autofill field name, e.g. to change it from "off" to "on" to allow values to be remembered and prefilled despite the page author's objections, or to always "off", never remembering values. However, user agents should not allow users to trivially override the autofill field name from "off" to "on" or other values, as there are significant security implications for the user if all values are always remembered, regardless of the site's preferences.
So in the case of Chrome, the developers have essentially said "we will leave this to the user to decide in their preferences whether they want autocomplete to work or not. If you don't want it, don't enable it in your browser".
However, it appears that this is a little over-zealous on their part for my liking, but it is the way it is. The specification also discusses the potential security implications of such a move:
The "off" keyword indicates either that the control's input data is particularly sensitive (for example the activation code for a nuclear weapon); or that it is a value that will never be reused (for example a one-time-key for a bank login) and the user will therefore have to explicitly enter the data each time, instead of being able to rely on the UA to prefill the value for him; or that the document provides its own autocomplete mechanism and does not want the user agent to provide autocompletion values.
So after experiencing the same frustration as everyone else, I found a solution that works for me. It is similar in vein to the autocomplete="false" answers.
A Mozilla article speaks to exactly this problem:
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
In some case, the browser will keep suggesting autocompletion values even if the autocomplete attribute is set to off. This unexpected behavior can be quite puzzling for developers. The trick to really force the no-completion is to assign a random string to the attribute
So the following code should work:
autocomplete="nope"
And so should each of the following:
autocomplete="false"
autocomplete="foo"
autocomplete="bar"
The issue I see is that the browser agent might be smart enough to learn the autocomplete attribute and apply it next time it sees the form. If it does do this, the only way I can see to still get around the problem would be to dynamically change the autocomplete attribute value when the page is generated.
One point worth mentioning is that many browser will ignore autocomplete settings for login fields (username and password). As the Mozilla article states:
For this reason, many modern browsers do not support autocomplete="off" for login fields.
If a site sets autocomplete="off" for a form, and the form includes username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits this page.
If a site sets autocomplete="off" for username and password input fields, then the browser will still offer to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits this page.
This is the behavior in Firefox (since version 38), Google Chrome (since 34), and Internet Explorer (since version 11).
Finally a little info on whether the attribute belongs on the form element or the input element. The spec again has the answer:
If the autocomplete attribute is omitted, the default value corresponding to the state of the element's form owner's autocomplete attribute is used instead (either "on" or "off"). If there is no form owner, then the value "on" is used.
So. Putting it on the form should apply to all input fields. Putting it on an individual element should apply to just that element (even if there isn't one on the form). If autocomplete isn't set at all, it defaults to on.
Summary
To disable autocomplete on the whole form:
<form autocomplete="off" ...>
Or if you dynamically need to do it:
<form autocomplete="random-string" ...>
To disable autocomplete on an individual element (regardless of the form setting being present or not)
<input autocomplete="off" ...>
Or if you dynamically need to do it:
<input autocomplete="random-string" ...>
And remember that certain user agents can override even your hardest fought attempts to disable autocomplete.
TL;DR: Tell Chrome that this is a new password input and it won't provide old ones as autocomplete suggestions:
<input type="password" name="password" autocomplete="new-password">
autocomplete="off" doesn't work due to a design decision - lots of research shows that users have much longer and harder to hack passwords if they can store them in a browser or password manager.
The specification for autocomplete has changed, and now supports various values to make login forms easy to auto complete:
<!-- Auto fills with the username for the site, even though it's email format -->
<input type="email" name="email" autocomplete="username">
<!-- current-password will populate for the matched username input -->
<input type="password" autocomplete="current-password" />
If you don't provide these Chrome still tries to guess, and when it does it ignores autocomplete="off".
The solution is that autocomplete values also exist for password reset forms:
<label>Enter your old password:
<input type="password" autocomplete="current-password" name="pass-old" />
</label>
<label>Enter your new password:
<input type="password" autocomplete="new-password" name="pass-new" />
</label>
<label>Please repeat it to be sure:
<input type="password" autocomplete="new-password" name="pass-repeat" />
</label>
You can use this autocomplete="new-password" flag to tell Chrome not to guess the password, even if it has one stored for this site.
Chrome can also manage passwords for sites directly using the credentials API, which is a standard and will probably have universal support eventually.
Always working solution
I've solved the endless fight with Google Chrome with the use of random characters. When you always render autocomplete with random string, it will never remember anything.
<input name="name" type="text" autocomplete="rutjfkde">
Hope that it will help to other people.
Update 2022:
Chrome made this improvement: autocomplete="new-password" which will solve it but I am not sure, if Chrome change it again to different functionality after some time.
The solution at present is to use type="search". Google doesn't apply autofill to inputs with a type of search.
See: https://twitter.com/Paul_Kinlan/status/596613148985171968
Update 04/04/2016: Looks like this is fixed! See http://codereview.chromium.org/1473733008
Browser does not care about autocomplete=off auto or even fills credentials to wrong text field?
I fixed it by setting the password field to read-only and activate it, when user clicks into it or uses tab-key to this field.
fix browser autofill in: readonly and set writeble on focus (at mouse click and tabbing through fields)
<input type="password" readonly
onfocus="$(this).removeAttr('readonly');"/>
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
By the way, more information on my observation:
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, sometimes even autocomplete=off would not prevent to fill in credentials into wrong fields, but not user or nickname field.
Chrome version 34 now ignores the autocomplete=off,
see this.
Lots of discussion on whether this is a good thing or a bad thing? Whats your views?
You can use autocomplete="new-password"
<input type="email" name="email">
<input type="password" name="password" autocomplete="new-password">
Works in:
Chrome: 53, 54, 55
Firefox: 48, 49, 50
[Works in 2021 for Chrome(v88, 89, 90), Firefox, Brave, Safari]
The old answers already written here will work with trial and error, but most of
them don't link to any official doc or what Chrome has to say on this
matter.
The issue mentioned in the question is because of Chrome's autofill feature, and here is Chrome's stance on it in this bug link - https://bugs.chromium.org/p/chromium/issues/detail?id=468153#c164
To put it simply, there are two cases -
[CASE 1]: Your input type is something other than password. In this case, the solution is simple, and has three steps.
Add name attribute to input
name should not start with a value like email or username, otherwise Chrome still ends up showing the dropdown. For example, name="emailToDelete" shows the dropdown, but name="to-delete-email" doesn't. Same applies for autocomplete attribute.
Add autocomplete attribute, and add a value which is meaningful for you, like new-field-name
It will look like this, and you won't see the autofill for this input again for the rest of your life -
<input type="text/number/something-other-than-password" name="x-field-1" autocomplete="new-field-1" />
[CASE 2]: input type is password
Well, in this case, irrespective of your trials, Chrome will show you the dropdown to manage passwords / use an already existing password. Firefox will also do something similar, and same will be the case with all other major browsers. [1]
In this case, if you really want to stop the user from seeing the dropdown to manage passwords / see a securely generated password, you will have to play around with JS to switch input type, as mentioned in the other answers of this question.
[1] A detailed MDN doc on turning off autocompletion - https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
Autocomplete="Off" doesn't work anymore.
Try using just a random string instead of "Off", for example Autocomplete="NoAutocomplete"
I hope it helps.
I am posting this answer to bring an updated solution to this problem.
I am currently using Chrome 49 and no given answer work for this one.
I am also looking for a solution working with other browsers and previous versions.
Put this code on the beginning of your form
<div style="display: none;">
<input type="text" autocomplete="new-password">
<input type="password" autocomplete="new-password">
</div>
Then, for your real password field, use
<input type="password" name="password" autocomplete="new-password">
Comment this answer if this is no longer working or if you get an issue with another browser or version.
Approved on:
Chrome : 49
Firefox : 44, 45
Edge : 25
Internet Explorer : 11
Seen chrome ignore the autocomplete="off", I solve it with a stupid way which is using "fake input" to cheat chrome to fill it up instead of filling the "real" one.
Example:
<input type="text" name="username" style="display:none" value="fake input" />
<input type="text" name="username" value="real input"/>
Chrome will fill up the "fake input", and when submit, server will take the "real input" value.
No clue why this worked in my case, but on chrome I used autocomplete="none" and Chrome stopped suggesting addresses for my text field.
Writing a 2020+ answer in case if this helps anyone. I tried many combinations above, though there is one key that was missed in my case. Even though I had kept autocomplete="nope" a random string, it didn't work for me because I had name attribute missing!
so I kept name='password'
and autocomplete = "new-password"
for username, I kept name="usrid" // DONT KEEP STRING THAT CONTAINS 'user'
and autocomplete = "new-password" // Same for it as well, so google stops suggesting password (manage password dropdown)
this worked very well for me.
(I did this for Android and iOS web view that Cordova/ionic uses)
<ion-input [type]="passwordType" name="password" class="input-form-placeholder" formControlName="model_password"
autocomplete="new-password" [clearInput]="showClearInputIconForPassword">
</ion-input>
autocomplete="off" is usually working, but not always. It depends on the name of the input field. Names like "address", 'email', 'name' - will be autocompleted (browsers think they help users), when fields like "code", "pin" - will not be autocompleted (if autocomplete="off" is set)
My problems was - autocomplete was messing with google address helper
I fixed it by renaming it
from
<input type="text" name="address" autocomplete="off">
to
<input type="text" name="the_address" autocomplete="off">
Tested in chrome 71.
Some end 2020 Update. I tried all the old solutions from different sites. None of them worked! :-(
Then I found this:
Use
<input type="search"/>
and the autocomplete is gone!
Success with Chrome 86, FireFox, Edge 87.
autocomplete=off is largely ignored in modern browsers - primarily due to password managers etc.
You can try adding this autocomplete="new-password" it's not fully supported by all browsers, but it works on some
to anyone looking for a solution to this, I finally figure it out.
Chrome only obey's the autocomplete="off" if the page is a HTML5 page (I was using XHTML).
I converted my page to HTML5 and the problem went away (facepalm).
Change input type attribute to type="search".
Google doesn't apply auto-fill to inputs with a type of search.
Up until just this last week, the two solutions below appeared to work for Chrome, IE and Firefox. But with the release of Chrome version 48 (and still in 49), they no longer work:
The following at the top of the form:
<input style="display:none" type="text" name="fakeUsername"/>
<input style="display:none" type="password" name="fakePassword"/>
The following in the password input element:
autocomplete="off"
So to quickly fix this, at first I tried to use a major hack of initially setting the password input element to disabled and then used a setTimeout in the document ready function to enable it again.
setTimeout(function(){$('#PasswordData').prop('disabled', false);}, 50);
But this seemed so crazy and I did some more searching and found #tibalts answer in Disabling Chrome Autofill. His answer is to use autocomplete="new-password" in the passwords input and this appears to work on all browsers (I have kept my fix number 1 above at this stage).
Here is the link in the Google Chrome developer discussion:
https://code.google.com/p/chromium/issues/detail?id=370363#c7
After the chrome v. 34, setting autocomplete="off" at <form> tag doesn`t work
I made the changes to avoid this annoying behavior:
Remove the name and the id of the password input
Put a class in the input (ex.: passwordInput )
(So far, Chrome wont put the saved password on the input, but the form is now broken)
Finally, to make the form work, put this code to run when the user click the submit button, or whenever you want to trigger the form submittion:
var sI = $(".passwordInput")[0];
$(sI).attr("id", "password");
$(sI).attr("name", "password");
In my case, I used to hav id="password" name="password" in the password input, so I put them back before trigger the submition.
I had a similar issue where the input field took either a name or an email. I set autocomplete="off" but Chrome still forced suggestions. Turns out it was because the placeholder text had the words "name" and "email" in it.
For example
<input type="text" placeholder="name or email" autocomplete="off" />
I got around it by putting a zero width space into the words in the placeholder. No more Chrome autocomplete.
<input type="text" placeholder="nam​e or emai​l" autocomplete="off" />
Instead of autocomplete="off" use autocomplete="false" ;)
from: https://stackoverflow.com/a/29582380/75799
In Chrome 48+ use this solution:
Put fake fields before real fields:
<form autocomplete="off">
<input name="fake_email" class="visually-hidden" type="text">
<input name="fake_password" class="visually-hidden" type="password">
<input autocomplete="off" name="email" type="text">
<input autocomplete="off" name="password" type="password">
</form>
Hide fake fields:
.visually-hidden {
margin: -1px;
padding: 0;
width: 1px;
height: 1px;
overflow: hidden;
clip: rect(0 0 0 0);
clip: rect(0, 0, 0, 0);
position: absolute;
}
You did it!
Also this will work for older versions.
I managed to disable autocomple exploiting this rule:
Fields that are not passwords, but should be obscured, such as credit
card numbers, may also have a type="password" attribute, but should
contain the relevant autocomplete attribute, such as "cc-number" or
"cc-csc".
https://www.chromium.org/developers/design-documents/create-amazing-password-forms
<input id="haxed" type="password" autocomplete="cc-number">
However it comes with the great responsibility :)
Don’t try to fool the browser Password managers (either built into the
browser, or external) are designed to ease the user experience.
Inserting fake fields, using incorrect autocomplete attributes or
taking advantage of the weaknesses of the existing password managers
simply leads to frustrated users.
Update 08/2022:
I managed to get autocomplete to be respected by including
autocomplete="new-password"
on each individual input element regardless of type.
E.g.
<input id="email" type="email" autocomplete="new-password"/>