This one is IE specific (not anymore, apparently). We have very simple code:
<div draggable="true">
<p>Text</p>
<input type="text"/>
</div>
On Chrome it works fine, you can select all text inside <input>, eg. double-click it or click-and-drag. On IE10 you cannot do both of these actions (not sure about IE in other versions). Any ideas?
Fiddle: http://jsfiddle.net/s5g4gr8g/
This was reported as a bug a few months back and is currently being considered for a future release.
One of the hold-ups is that we are unable to determine the impact of the issue. I recall searching online and on GitHub for sites that relied on this pattern, but largely came up empty-handed. If you happen to know of any sites that use this, and are therefore broken in Internet Explorer 10 and 11, I would be happy to update the internal issue and request immediate action.
That being said, it does appear you can select text if you tab focus to the element itself, and then utilize the arrow and shift keys to perform your selection. You can also right-click the input control, which also places a cursor that you can then manipulate with your keyboard. It's not ideal, but it may suffice until we can resolve this from the browser-end.
One possible workaround to this solution is to remove the draggable attribute from the parent element in situations where you expect the text to be highlighted.
For instance in an application I'm working on, we show text in a span by default, then reveal an input when the user clicks on it to edit. At that point we remove the draggable attribute until the user is done editing, and then readd it.
That particular flow may or may not work for you, but if you can anticipate when the user might highlight, you can minimize the effect of the undesirable browser behavior. At minimum you can toggle draggable on focus and blur so that the user can highlight with the mouse if he's already editing the text.
The way Ben McCormick mentioned works good for me on the major browsers (tested with Internet Explorer 11, Firefox and Chrome).
For my solution you need to have an criteria to determine the parent with the draggable attribute (in my case I use a class name for that).
function fixSelectable(oElement, bGotFocus)
{
var oParent = oElement.parentNode;
while(oParent !== null && !/\bdraggable\b/.test(oParent.className))
oParent = oParent.parentNode;
if(oParent !== null)
oParent.draggable = !bGotFocus;
}
<div class="draggable" draggable="true">
<p>Text</p>
<input type="text" onfocus="fixSelectable(this, true)" onblur="fixSelectable(this, false)"/>
</div>
What we observed, if we blur out and focus again the issue is resolved. However moving cursor position is still not accomplished. But at least does the trick for single click.
$(document).on('mouseup', '#id input:text, textarea', function (event) {
$(this).blur();
$(this).focus();
});
When using the xhtml1-transitional.dtd doctype, collecting a credit card number with the following HTML
<input type="text" id="cardNumber" name="cardNumber" autocomplete='off'/>
will flag a warning on the W3C validator:
there is no attribute "autocomplete".
Is there a standards-compliant way to disable browser auto-complete on sensitive fields in a form?
Here is a good article from the MDC which explains the problems (and solutions) to form autocompletion.
Microsoft has published something similar here, as well.
To be honest, if this is something important to your users, 'breaking' standards in this way seems appropriate. For example, Amazon uses the 'autocomplete' attribute quite a bit, and it seems to work well.
If you want to remove the warning entirely, you can use JavaScript to apply the attribute to browsers that support it (IE and Firefox are the important browsers) using someForm.setAttribute( "autocomplete", "off" ); someFormElm.setAttribute( "autocomplete", "off" );
Finally, if your site is using HTTPS, IE automatically turns off autocompletion (as do some other browsers, as far as I know).
Update
As this answer still gets quite a few upvotes, I just wanted to point out that in HTML5, you can use the 'autocomplete' attribute on your form element. See the documentation on W3C for it.
I would be very surprised if W3C would have proposed a way that would work with (X)HTML4. The autocomplete feature is entirely browser-based, and was introduced during the last years (well after the HTML4 standard was written).
Wouldn't be surprised if HTML5 would have one, though.
Edit: As I thought, HTML5 does have that feature. To define your page as HTML5, use the following doctype (i.e: put this as the very first text in your source code). Note that not all browsers support this standard, as it's still in draft-form.
<!DOCTYPE html>
HTML 4: No
HTML 5: Yes
The autocomplete attribute is an enumerated attribute. The attribute
has two states. The on keyword maps to the on state, and the off
keyword maps to the off state. The attribute may also be omitted. The
missing value default is the on state. The off state indicates that by
default, form controls in the form will have their autofill field name
set to off; the on state indicates that by default, form controls in
the form will have their autofill field name set to "on".
Reference: W3
No, but browser auto-complete is often triggered by the field having the same name attribute as fields that were previously filled out. If you could rig up a clever way to have a randomized field name, autocomplete wouldn't be able to pull any previously entered values for the field.
If you were to give an input field a name like "email_<?= randomNumber() ?>", and then have the script that receives this data loop through the POST or GET variables looking for something matching the pattern "email_[some number]", you could pull this off, and this would have (practically) guaranteed success, regardless of browser.
No, a good article is here in Mozila Wiki.
I would continue to use the invalid attribute. I think this is where pragmatism should win over validating.
How about setting it with JavaScript?
var e = document.getElementById('cardNumber');
e.autocomplete = 'off'; // Maybe should be false
It's not perfect, but your HTML will be valid.
I suggest catching all 4 types of input:
$('form,input,select,textarea').attr("autocomplete", "off");
Reference:
http://www.w3.org/Submission/web-forms2/#the-autocomplete
http://dev.w3.org/html5/markup/input.html
If you use jQuery, you can do something like that :
$(document).ready(function(){$("input.autocompleteOff").attr("autocomplete","off");});
and use the autocompleteOff class where you want :
<input type="text" name="fieldName" id="fieldId" class="firstCSSClass otherCSSClass autocompleteOff" />
If you want ALL your input to be autocomplete=off, you can simply use that :
$(document).ready(function(){$("input").attr("autocomplete","off");});
Another way - which will also help with security is to call the input box something different every time you display it: just like a captha. That way, the session can read the one-time only input and Auto-Complete has nothing to go on.
Just a point regarding rmeador's question of whether you should be interfering with the browser experience: We develop Contact Management & CRM systems, and when you are typing other people's data into a form you don't want it constantly suggesting your own details.
This works for our needs, but then we have the luxury of telling users to get a decent browser:)
autocomplete='off'
autocomplete="off" this should fix the issue for all modern browsers.
<form name="form1" id="form1" method="post" autocomplete="off"
action="http://www.example.com/form.cgi">
[...]
</form>
In current versions of Gecko browsers, the autocomplete attribute works perfectly. For earlier versions, going back to Netscape 6.2, it worked with the exception for forms with "Address" and "Name"
Update
In some cases, 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 forcing the no-autocompletion is to assign a random string to the attribute, for example:
autocomplete="nope"
Since this random value is not a valid one, the browser will give up.
Documetation
Using a random 'name' attribute works for me.
I reset the name attribute when sending the form so you can still access it by name when the form is sent. (using the id attribute to store the name)
Note that there's some confusion about location of the autocomplete attribute. It can be applied either to the whole FORM tag or to individual INPUT tags, and this wasn't really standardized before HTML5 (that explicitly allows both locations). Older docs most notably this Mozilla article only mentions FORM tag. At the same time some security scanners will only look for autocomplete in INPUT tag and complain if it's missing (even if it is in the parent FORM). A more detailed analysis of this mess is posted here: Confusion over AUTOCOMPLETE=OFF attributes in HTML forms.
Not ideal, but you could change the id and name of the textbox each time you render it - you'd have to track it server side too so you could get the data out.
Not sure if this will work or not, was just a thought.
I think there's a simpler way.
Create a hidden input with a random name (via javascript) and set the username to that. Repeat with the password. This way your backend script knows exactly what the appropriate field name is, while keeping autocomplete in the dark.
I'm probably wrong, but it's just an idea.
if (document.getElementsByTagName) {
var inputElements = document.getElementsByTagName("input");
for (i=0; inputElements[i]; i++) {
if (inputElements[i].className && (inputElements[i].className.indexOf("disableAutoComplete") != -1)) {
inputElements[i].setAttribute("autocomplete","off");
}
}
}
I MADE THIS WORK IN 2020!
I basically create a css class that applies -webkit-text-security to my inputs.
Here's the link to a more recent discussion:
https://stackoverflow.com/a/64471795/8754782
This solution works with me:
$('form,input,select,textarea').attr("autocomplete", "nope");
if you want use autofill in this region: add autocomplete="false" in element
ex:
<input id="search" name="search" type="text" placeholder="Name or Code" autcomplete="false">
Valid autocomplete off
<script type="text/javascript">
/* <![CDATA[ */
document.write('<input type="text" id="cardNumber" name="cardNumber" autocom'+'plete="off"/>');
/* ]]> */
</script>
I have a <input type = 'file'>. To enable/disable it I use jQuery("#my_input").prop('disabled' ,true/false).
If I disable it, then refresh the page, jQuery outputs:
console.log(jQuery("#my_input").prop('disabled' )) ==> true
even though the 'disabled' prop is not included in the html.
Clearing the cache does not fix it.
Firefox has long been saving input values through refreshes, and now the latest builds also save input / button's disabled status through refreshes.
I'm not sure whether this is intended or a bug, but for the time being an workaround is to just set the inputs' disabled status to their default ones inside a DOM ready handler.
jQuery(function($) {
$("#my_input").prop('disabled', false);
});
Demonstrating the issue: Fiddle (open with Firefox)
And now fixed with the snippet above: Fiddle
You can also apply autocomplete="off" to the element and its disabled status won't persist through refreshes.
Fiddle
Note that this will prevent any form of auto-completion in the element. Of course, this is an excellent solution for file inputs and buttons, however depending on your use case (e.g. when it involves text inputs) you may prefer the former solution. Thanks to #dsdsdsdsd for the tip!
p.s. This has been reported to Mozilla already: Bugzilla ticket.
Firefox should include it in html also.
What happens if you use:
jQuery("#my_input").attr('disabled' ,true)
I have an issue perhaps very similar to
How do I make a required radio input optional in Firefox using JavaScript?
My example can be found here:
http://www.bradkent.com/?page=test/ff_radio
In a nutshell, I have an event viewer on a checkbox that toggles the visibility of a radio group. The radio group is initially required, but when hidden, I change the radio inputs' required property to false (node.required = false). When the group is re-shown, the required property is changed back to true.
the dom inspector confirms that neither the required attribute or property is set.
So why is it requiring an option to be selected?
What am I doing wrong, or overlooking?
Thank you
well, I figured out the issue
node.required = true/false vs node.setAttribute('required',1); and node.removeAttribute('required');
the former had been done earlier in the code and at that point node.removeAttribute('required'); node.removeProp('required'); etc were all of no use in removing the required property (in Firefox)
I have statement $("#myDiv").attr("disabled","disabled");
I thought that once I disable "parent" container, all elements inside of this become disabled. What I see actually, that text-box looks like disabled and "delete" not works within, but I can type there. check-box that inside of the same div, really looks disabled and I can't check/uncheck it. I'm not sure for 100%, but I think that I already used disabling that way and it worked as I expected (text-box not typeble). So I want to know if I need explicitly set disabled for textboxes or maybe some other CSS breaks what I'm expecting.
UPDATE:
I know how to set disable explicitly for elements that i need, I just not want tot do it and what I'm asking that if it the only way to disable it, or textbox may work exactly as checkbox (without explicitly disabling it) and just some CSS breaks this behavior.
As far as im aware doing that is not cross browser friendly nor valid markup. Best option would be to do something like
$('#myDiv').find('input,textarea,select').attr("disabled", true);
That should find all form elements within the div and apply teh disabled flag directly
Edit: or even just
$('input,textarea,select', '#myDiv').attr("disabled", true);
You can use the :input selector:
$("#myDiv :input").attr("disabled", true);