Is it possible to use CSS to disable autocomplete on a form element (specifically a textfield)?
I use a tag library which does not permit the autocomplete element and I would like to disable autocomplete without using Javascript.
As it stands, there is no 'autocomplete off' attribute in CSS. However, html has an easy code for this:
<input type="text" id="foo" value="bar" autocomplete="off" />
If you're looking for a site-wide effector, an easy one would be to simply have a js function to run through all 'input' s and add this tag, or look for the corresponding css class / id.
The autocomplete attribute works fine in Chrome and Firefox (!), but see also Is there a W3C valid way to disable autocomplete in a HTML form?
You can use a generated id and name everytime, which is different, so the browser cannot remember this text-field and will fail to suggest some values.
This is at least the cross browser safe alternative, but I would recommend to go with the answer from RobertsonM (autocomplete="off").
you can easily implement by jQuery
$('input').attr('autocomplete','off');
If you're using a form you can disable all the autocompletes with,
<form id="Form1" runat="server" autocomplete="off">
CSS does not have this ability. You would need to use client-side scripting.
I tried all suggested ways from this question answers and other articles in the web but not working anyway. I tried autocomplete="new-random-value", autocomplete="off" in form element, using client-side script as below but outside of $(document).ready() as one of the user mentioned:
$(':input').on('focus', function () {
$(this).attr('autocomplete', 'off')
});
I found maybe another priority in the browser cause this weird behavior! So I searched more and finally, I read again carefully below lines from this good article:
For this reason, many modern browsers do not support
autocomplete="off" for login fields:
If a site sets autocomplete="off" for a , 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 the page. If a
site sets autocomplete="off" for username and password 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 the page. This is the behavior in Firefox (since version
38), Google Chrome (since 34), and Internet Explorer (since version
11).
If you are defining a user management page where a user can specify a
new password for another person, and therefore you want to prevent
auto-filling of password fields, you can use
autocomplete="new-password"; however, support for this value has not been implemented on Firefox.
It's just worked. I tried in chrome specially and I hope this continues working and help others.
There are 3 ways to that, i mention them in order of being the better way...
1-HTML way:
<input type="text" autocomplete="off" />
2-Javascript way:
document.getElementById("input-id").getAttribute("autocomplete") = "off";
3-jQuery way:
$('input').attr('autocomplete','off');
I solved the problem by adding an fake autocomplete name for all inputs.
$("input").attr("autocomplete", "fake-name-disable-autofill");
I just use 'new-password' instead 'off' on autocomplete.
and I also have try using this code and works (at least on my end), I use WP and GravityForm for your information
$('input').attr('autocomplete','new-password');
Thanks to #ahhmarr's solution I was able to solve the same problem in my Angular+ui-router environment, which I'll share here for whoever's interested.
In my index.html I've added the following script:
<script type="text/javascript">
setTimeout(function() {
$('input').attr('autocomplete', 'off');
}, 2000);
</script>
Then to cover state changes, I've added the following in my root controller:
$rootScope.$on('$stateChangeStart', function() {
$timeout(function () {
$('input').attr('autocomplete', 'off');
}, 2000);
});
The timeouts are for the html to render before applying the jquery.
If you find a better solution please let me know.
You can't use CSS to disable autocomplete, but you can use HTML:
<input type="text" autocomplete="false" />
Technically you can replace false with any invalid value and it'll work. This iOS the only solution I've found which also works in Edge.
Related
I have a button with the "disabled" attribute, that I enable using jQuery when certain conditions are met. The problem is that Firefox doesn't read the "disabled" attribute, even though Chrome&IE have no problem.
My code is <button disabled type="button" class="btn btn-secondary button_confirm" title="Title here">Confirm</button>
I also tried disabled=true and disabled=disabled but nothing seems to work.
Can anyone please help? Thank you.
Sorry, just figured it out. The problem was that firefox stored my previous tries in cache, and javascript enabled the button because the condition was met (from previous tries). Thank you and sorry for wasting your time
I believe the problem is not that the disabled property isn't read by Firefox, but that you're not modifying it properly using JQuery.
If you are using jQuery < 1.6, change the attribute using this command:
$('.button_confirm).attr("disabled", 'disabled');
If you are using jQuery >= 1.6, change the attribute using this command:
$('.button_confirm).prop("disabled", true);
I have an admin form with username and password fields that is being filled in by Chrome as it has a username and password remembered.
I would like to prevent these fields to be automatically filled.
I did lots of search and already tried the autocomplete tag (in input and form), displany:none in style tag and the javascript call to dissabled autocomplete... and nothing of these worked.
Can you please give me a hand?
Thanks!
link to gist https://gist.github.com/runspired/b9fdf1fa74fc9fb4554418dea35718fe
<!--
<form autocomplete="off"> will turn off autocomplete for the form in most browsers
except for username/email/password fields
-->
<form autocomplete="off">
<!-- fake fields are a workaround for chrome/opera autofill getting the wrong fields -->
<input id="username" style="display:none" type="text" name="fakeusernameremembered">
<input id="password" style="display:none" type="password" name="fakepasswordremembered">
<!--
<input autocomplete="nope"> turns off autocomplete on many other browsers that don't respect
the form's "off", but not for "password" inputs.
-->
<input id="real-username" type="text" autocomplete="nope">
<!--
<input type="password" autocomplete="new-password" will turn it off for passwords everywhere
-->
<input id="real-password" type="password" autocomplete="new-password">
</form>
I found a work around for chrome. I have not tried this on any other browser. Load the password field as a type="text" then when the page is finished loading change the type to password chrome will not autofill the username and password.
<input type="text" name="newPassword" id="newPassword" value="" class="form-control" autocomplete="off">
<script type="text/javascript">
$(document).ready(function(){
$('#newPassword').attr('type', 'password');
});
</script>
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.
Bugzilla Bug 956906 - ignore autocomplete="off" when offering to save passwords via the password manager
Reddit discussion
Chrome's announcement when they began ignoring autocomplete=off
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
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 they 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.™
tl;dr: My browser is going to remember my login for your web-site. If you don't like it: that's your problem. I will not sacrifice my preferences for yours.
Put it another way
There is a lot of confusion, or disagreement, on these points. Let me clarify, and put it as plainly as i possibly can:
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.
And if i don't want the value saved, i will click Nope:
Neither you, nor your managers, nor HIPPA, nor the EU, nor the GDPR, get to over-rule my wishes. It's my browser. I'm the user. I'm in charge.
If you have a different opinion
on how your browser should behave
then you
can configure your browser
to suit your personal preferences
But you don't get to impose them on anyone else.
But it's a HIPPA-PCI-GDPR-PII violation if we allow passwords to be saved. We need auto-filling turned off!
No, you don't. I'm right. You're wrong. And every browser agrees with me. If you don't like something, i suggest you talk to a therapist about it.
Adding autocomplete="something" attributes does not help me.
My form has text type input and Chrome constantly filled it with login data.
Adding hidden text type input did not help too. But solution was adding pair hidden input fields with text and password types before visible inputs
<input type="text" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
<input type="password" style="width:0;height:0;visibility:hidden;position:absolute;left:0;top:0" />
Tested with Chrome Version 74
I ended up doing something like this:
<input type="password"
id="password-field"
onClick="yourFunction()"
class="form-control"/>
function yourFunction() {
var temporalValue = $('#password-field').val();
$('#password-field').val("");
$('#password-field').attr('type', 'text');
myAjaxRequestPromise(temporalValue).then(function(version) {
//more logic
}, function(errorResponse) {
// Just a hack to fool browsers and do not store my password
$('#password-field').val(temporalValue);
$('#password-field').attr('type', 'password');
// more logic
});
}
And always make sure the $('#password-field').val("") initializes the field without values, it could be whenever you show your modal or on the load page callback
It seems to be working fine for Safari/Chrome/Firefox
It basically switches between input types before doing the Ajax request to the server and in case there is an error we set back again the old value to the input.
I found the solution. !!!!
PROBLEM
my problem was that the username and password saved in the browser was automatically filling my register form
REASON
The problem here is that the password input type is password. it automatically fills in as username without knowing what the parent entry is.
SOLUTION
Adding autocomplete="new-password" to the password entry solved my problem.
It also works in Firefox and chrome. I haven't tested the others.
<input
id="txtSetPassword"
[formControlName]="formControlName"
[type]="show ? 'text' : 'password'"
class="input"
autocomplete="new-password"
[placeholder]="'loginPasswordForm.password.placeholder' | cxTranslate"
/>
In HTML 5 you can do it in one of two ways...
<form action="demo_form.asp" autocomplete="off">
Or an individual control
<input type="email" name="email" autocomplete="off">
For more info - http://www.w3schools.com/html/html5_form_attributes.asp
I have added a back form button to my website, which works great, but i am wondering if it is possible to replace it with a home button if a visitor has just landed on my website.
This is my form button:
<FORM><INPUT VALUE='Back' id='backbutton' onClick='history.go(-1);return true;' type='button'/></FORM>
and i want it to be replaced by this if visitors have just landed on my website:
<FORM><INPUT VALUE='Home' id='homebutton' onClick='href="http://www.gamer4eva.com/"' type='button'/></FORM>
You could see if the visitor is from your site with $_SERVER['HTTP_REFERER']
Best use preg_match on it to get the domain, and if its not your site that means they came from somewhere else.
This is not 100% accurate though, since users can edit the HTTP_REFERER value.
Good luck
This is a clientside solution:
onClick="(document.referrer.match('gamer4eva.com') || document.referrer === "")?href='http://www.gamer4eva.com/':history.go(-1)"
and you don't need a form for that. Better use an anchor:
Back
of course you could also check this serverside. Depends on your taste.
I'm getting some very strange behaviour from a file input element in both Chrome and Opera (possibly more, haven't tested).
I have the following HTML:
<div id="profileImgContainer" class="formFile">
<label>Profile Picture</label><div>
<input type="text" id="profileImgText"><input type="button" value="Choose File" id="profileImgButton">
</div>
<input type="file" id="profileImg" name="profileImg">
</div>
And the following jQuery to get the file input's value and put it in the (visible) textbox. The actual file input is hidden.
$(".formFile input[type='file']").live('change', function()
{
$(this).parents(".formFile").find("input[type='text']").val($(this).val());
});
I've made a JSFiddle for you try out. In Firefox, the text box happily takes the filename (don't care about the path) of the file element. In Chrome and Opera, however, when a file is selected the file path in the visible text box changes to C:\fakepath\[filename] where [filename] is the name of the file chosen. This path is obviously fake but what I want to know is why it's changed to it, and whether the file in the hidden upload element will still upload fine. I'm guessing it's a security feature, but I may be wrong.
This is one attempt to mitigate the security issues you get from allowing arbitrary foreign code to run in your browser: The script (which we assume could come from a malicious attacker) does not get to see (and possibly communicate back via AJAX) information about your local files.
Imagine what could happen if a script could just freely set file uploads and submit forms.
This behaviour concerning file upload controls and scripting is mandated by some sort of standard (I believe part of the DOM specification) for this very reason.
I just want to add a new answer for people facing this issue nowadays. Similar to one of the comments, it's better to use the input element itself. For example:
document.getElementById('file-input').files[0].path
This worked for me.
Similar solution for React:
const inpRef = useRef(null)
return (
<input type="file" onChange={() => {
const filePath = inpRef.current.files[0].path
// You can use more properties by looking at the files object
}} />
)
I have implemented paypal in my web page. Process is 'given inputs are redirect to other page(2 nd page) which have to get that input and redirect to paypal page(third page). Here we submit data on first page. value pass to second page(in this page user interaction not allowed) after pass to third page.It works fine in IE . But Not In Mozila.Send any Solution.
Code sample(second page):
<%string product = Request.QueryString["productName"].ToString();%>
<% string amount = Request.QueryString["price"].ToString(); %>
">
">
document.all.frmpaypal.submit();
Fine in IE, Not In Mozila
document.getElementById("frmpaypal").submit();
document.all is an IE-only non-standard extension. You can use:
document.getElementById("frmpaypal").submit();
Which will work on both browsers. Better yet, use something like jQuery:
$("#frmpaypal").submit();
(This simple example doesn't really show you the power of jQuery, but you'll love it once you find out everything it can do!)
document.all is non-standard. Add an ID and use document.getElementById.
Have you checked into the possibility of sending values via GET instead of POST in the FORM's action attribute?