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:   <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"
I have a contact form on a website that has been receiving a lot of spam. It is hosting on Github so my methods of server side validation / captcha is quite limited. All fields always had the 'required' attribute and I have added some 'pattern' attributes to the form field and a very basic security question.
Originally I would receive spam responses with all fields completed but random numbers where the name should be, a name where the phone number should be, an email, and URLs in the message area.
When I first added just the security question handled by javascript / jquery, it seems to have no effect so I am assuming the bot could read the correct answer from the code?? What is more concerning, is that after more recently adding some 'pattern' attribute to the form fields I have started getting spam responses that still contain random numbers where the name should be, and now the phone and email field is non existent (not submitted / entered).
I do not get how the field can be submitted when it doesnt match the pattern validation, or how two fields can be left blank when they still have the 'required' attribute. I have tested the form myself and all validation and required fields function as expected and all fields are received like they used to be so it is just the spammer that seems to ignore these rules.
If anyone can please explain what may be happening / have happened here?? Also / alternatively if anyone is aware of a better and proven way of weeding out spam responses that works with the form I have and within the constraints of hosting the website on Github that would be GREATLY appreciated!!
The website in question is http://orionimportgroup.com/ if you would like to see the form in the live environment.
var n1 = Math.round(Math.random() * 10 + 1);
var n2 = Math.round(Math.random() * 10 + 1);
$('document').ready(function(){
$("#a").val(n1 + " + " + n2);
document.getElementsByName('captcha')[0].placeholder=("CAPTCHA CODE: " + n1 + "+" + n2);
});
$('form').submit(function(e) {
if (eval($("#captcha").val()) == (parseInt(n1) + parseInt(n2))) {
e.preventDefault();
$.ajax({
url: "https://docs.google.com/a/blakedavies.net/forms/d/e/1FAIpQLSfHdHMJePTJ3R5JOtBrH8zdPdX74eXQ8TDFIGjgkbIbGNdpnQ/formResponse",
data: $(this).serialize(),
type: "POST",
dataType: "xml",
success: function(data) {
console.log('Submission successful');
},
error: function(xhr, status, error) {
console.log('Submission failed: ' + error);
}
});
$('#gform *').fadeOut(0);
$('#contact-box *').fadeOut(0);
$('#gform').prepend(
'<div class="thank-you-box"><p class="thank-you">Hi, thanks for reaching out! We will get back to you within 24 hours.</p><p class="thank-you">If your issue cannot wait, you can also reach us via our Facebook Page or call 0429-105-580.</p></div>'
);
return true;
}
else{
alert('You have not entered the correct captcha code value');
return false;
}
});
<form name="gform" id="gform" enctype="text/plain" action="https://docs.google.com/a/blakedavies.net/forms/d/e/1FAIpQLSfHdHMJePTJ3R5JOtBrH8zdPdX74eXQ8TDFIGjgkbIbGNdpnQ/formResponse">
<div class="inner">
<input name="entry.1683926249" id="entry.1683926249" placeholder="Name" required pattern="[A-Za-z' -]+" oninvalid="setCustomValidity('Please enter a valid name using letters only.')" onchange="try{setCustomValidity('')}catch(e){}" />
<input name="entry.189066148" id="entry.189066148" placeholder="Phone" required pattern="[0-9 -]+" oninvalid="setCustomValidity('Please enter a valid phone number using numbers only.')" onchange="try{setCustomValidity('')}catch(e){}" />
<input name="entry.429019481" id="entry.429019481" placeholder="Email" required pattern="[a-z0-9._%+-]+#[a-z0-9.-]+.[a-z]{2,3}$" oninvalid="setCustomValidity('Please enter a valid email making sure to include an # sign and the domain suffix (.com .net etc.).')" onchange="try{setCustomValidity('')}catch(e){}" />
</div>
<div class="inner">
<textarea name="entry.2094840737" id="entry.2094840737" placeholder="Message" required></textarea>
<input name="captcha" id="captcha" placeholder="CAPTCHA CODE: 5+7" required />
</div>
<input class="submit" name="submit" type="submit" value="Send Message" />
</form>
<script src="js/contactform.js" type="text/javascript"></script>
One way to prevent spam is Honeypot technique, it is proven to work and prevented more than 90% of spam for my company's site.
To implement the Honeypot technique, all that’s required is adding a hidden form field to the form.
And that’s what gives away whether the form submission is spam or not:
Real users don’t see the hidden field so they won’t submit it with any value.
Spam bots, however, will still see the field in the form’s markup, auto-populate it with something, and submit it with the rest of the form.
So from there all that’s needed is to test whether the hidden field was submitted with a value or not. If it was, the submission can be treated as spam.
Read more about Honeypot technique
Response to comments and additional info (I can't comment yet)
#user7531422, try it like this:
Add a class to an additional input element (honeypot element) with CSS style to hide it display: none;, and make it look same as the name or phone field but change name attribute.
most bots will read only the HTML markup and won't notice CSS rules, and most bots aren't so smart to dive into every piece of code.
Before submitting the form directly check if your hidden field has data (Check for it value if not empty), if so don't even send the form.
It's a client side solution.
Is it possible after processing any login Form to prevent the browser from offering the option to remember the password?
I know it's been asked and answered here but none of the answers have worked so far, even one of them suggested using:
autocomplete="off"
But that also didn't worked.
I'm using AngularJS and Jade as templating engine (not sure if relevant or not anyhow), is there any way to do this?
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.
https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion
You should also set autocomplete="off" on your input as well as your form.
Google Chrome release notes:
The Google Chrome UI for auto-complete request varies, depending on whether autocomplete is set to off on input elements as well as their form. Specifically, when a form has autocomplete set to off and its input element's autocomplete field is not set, then if the user asks for autofill suggestions for the input element, Chrome might display a message saying "autocomplete has been disabled for this form." On the other hand, if both the form and the input element have autocomplete set to off, the browser will not display that message. For this reason, you should set autocomplete to off for each input that has custom auto-completion.
I would suggest using Javascript to create a random number. Pass that random number to your Server Action using a hidden field, then incorporate that random number into the names of the "login" and "password" fields.
E.g. (psuedo code, the exact syntax depends on whether you use PHP, jQuery, pure Javascript, etc.)
<script>
var number = Math.random();
var login_name = 'name_'+number;
var pass_word = 'pass_'+number;
</script>
<input name='number' value="number" type='hidden'>
<input name="login_name" type='text'>
<input name="pass_word" type='password'>
Your server reads the "number" field, then uses that to read "name_"number value and "pass_"number value.
It won't matter whether or not the user saves their password in the browser, since every time the user logs in, the name and password fields will be different.
Since you're using AngularJS, you can leave the field unnamed, and access the data it contains through the model :
Login: <input ng-model="login" type="text" />
Password: <input ng-model="password" type="password" autocomplete="off" />
and in your javascript file :
$scope.doLogin = function() {
var dataObj = {
login: $scope.login,
password: $scope.password
};
var res = $http.post('/login', dataObj);
}
Tested in IE10 and Chrome 54
This post is little bit old now, but sincce I found a solution that works for me (at least with Chrome version 56), I'll share it here.
If you remove name and password attributes on your input, then Chrome won't ask to save the password. Then you just have to add the missing attributes by code just before submitting the form:
<!-- Do not set "id" and "name" attributes -->
Login: <input type="text">
Password: <input type="password">
<!-- Handle submit action -->
<input type="submit" onclick="login(this)">
Then in Javascript:
function login(submitButton) {
var form = submitButton.form;
// fill input names by code before submitting
var inputs = $(form).find('input');
$(inputs[0]).attr('name', 'userName');
$(inputs[1]).attr('name', 'password');
form.submit();
}
I hope this will help. Tested on Chrome 56 only.
The problem I have is that while I understand the 'annoyance' to a user in not being able to have their browser remember their password and I don't want to 'disable' that feature completely, there are times when I want to disable it for just a certain password field. Example for me being a 'reset your password' dialogue box.
I want to force them to have to re-enter their old password and then of course type the new one twice.
It's been my experience that no matter what I name that 'old' password input, it is auto-filled with the 'remembered' password (in Firefox 49.0.1 anyway). Maybe this is where I'm getting this wrong, but it just fills it no matter the fact that this input's name is different from saying the login input field.
The behavior I see is basically that the browser seems to say "This user has remembered a password for this site, so now just fill every input type='password' box with that password no matter the name. It seems to me that this should be based on the name attribute, but for me (on multiple sites I've worked on) this just does not seem to be the case.
My solution:
Color this password field to the same color as the background of your input so the 'password dots' is essentially invisible on page load.
onload, onblur, after a timeout, or however you want to do it, use JQuery or JS to set the value of that password field to nothing (blank), then set the color of the field to whatever it is supposed to be.
$("#old_password").val('').css('color','black);
I've discovered that Firefox 52.0.2 is incredibly determined to remember the autocompletion values. I tried almost everything suggested above, including changing the name attributes to random values. The only thing that is working for me is setting the values to "" with Javascript after the browser has had its way with the form.
My use case is lucky in that I do not have to resort to CSS tricks to prevent a confusing and/or annoying flash of autocompleted form values (as proposed by #MinnesotaSlim above) because my form is hidden until they click a button; then it's displayed via a Bootstrap modal. Hence (with jQuery),
$('#my-button').on("click",function(){
$('#form-login input').val("");
});
// this also works nicely
$('#my-modal').on("show.bs.modal",function(){
$('#form-login input').val("");
})
And I imagine you might be able to get the same effect by having your form initially hidden, and in your document load event, manually override the browser and then display the form.
For me, the only solution that reliably worked was to empty username and password input element just before submitting form combined with replacing submit button for the regular button with onclick handler.
NOTE: We use Microsoft MVC so we needed to populate ViewModel with entered credentials. Therefore we created hidden input elements bound to model and copied credential values to them before emptying visible inputs.
<form>
<input id="UserName" name="UserName" type="hidden" value="">
<input id="Password" name="Password" type="hidden" value="">
</form>
<input id="boxUsr" name="boxUsr" type="text" value="" autocomplete="off">
<input id="boxPsw" name="boxPsw" type="password" autocomplete="off">
<input type="submit" value="Login" onclick="javascript:submitformforlogin()">
function submitformforlogin() {
$("[name='boxPsw'],[name='boxUsr']").attr('readonly','true');
var psw = document.getElementsByName('boxPsw')[0];
var usr = document.getElementsByName('boxUsr')[0];
if (psw.value != "false") {
$('#Password').val(psw.value);
$('#UserName').val(usr.value);
psw.value = "";
usr.value = "";
$("form").submit();
} else
window.alert("Error!");
}