Firefox caches hidden inputs - html

I have a hidden input field in my form. I noticed that if that field's value is changed by javascript, and then the user refreshes the page, that same value will be set when the page reloads. From what I've seen, this only happens in Firefox.
I've solved this unwanted behaviour by adding autocomplete="off" to that hidden input, but W3C doesn't like this solution, and if i validate the page I get the error:
Attribute autocomplete not allowed on element input at this point.
Apparently, the autocomplete attribute works only on specific inputs - see here.
So is there any solution that will satisfy both W3C and Firefox?

To validate (which I wouldn't put as much effort into as you are) I think you could use autocomplete="off" on the entire form, then turn it back on selectively, like this:
<!DOCTYPE html>
<html>
<head>
<title>TEST</title>
</head>
<body>
<form autocomplete="off">
<input type="hidden" name="test">
<input type="text" name="otherfield" autocomplete="on">
</form>
</body>
</html>
I initially thought this was a Firefox bug but after discussion with robertc in the comments, I think expected behavior depends on specific use cases. The spec doesn't allow autocompletion on hidden fields so my first reaction still feels right, but Firefox's implementation might have some good arguments to support it. Please comment.

Alternatively, you could use <input type="text" style="display: none;" autocomplete="off" /> instead. It's a bit of a hack, but it should work!
The caching in Firefox is actually quite a good feature a lot of the time, but it does cause some problems when you build more dynamic forms.

Related

Chrome/Firefox autocomplete=new-password not working

I'm trying to add autocomplete=new-password to some user-editing forms, but it fails to follow the correct behavior in Chrome 79 and Firefox 71. It's supposed to be supported in both browsers.
What's wrong here?
I created two very simple examples to remove any external interference to the issue. They can be served from any HTTP server (e.g. php -S localhost:8999). The first page triggers the "save login" feature, but the second should NOT use that info to autocomplete the password - yet, it does.
<!-- login.htm -->
<html>
<head></head>
<body>
<form action="edit.htm" method="post">
<label>Login <input type="text" name="login" /></label></br>
<label>Password <input type="password" name="pwd" /></label><br />
<input type="submit">
</form>
</body>
</html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login" /></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password" /></label><br />
<input type="submit">
</form>
</body>
</html>
This is not exactly a dup from "how to use autocomplete=new-password" as the behavior seems to have changed or is ill-documented.
This seems to be an issue/advantage that browsers force pages to behave this way, and absolutely this is not fixed when setting autocomplete="new-password" or even if you set the value to off. but there seems to be a workaround to fix this issue caused accidentally by the browser.
- HTML way:
You can fix this by adding hidden fields at the top of your form to distract the browser
<!-- 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">
- JS way:
you can just set the password input to readonly the change its state
<html>
<head></head>
<body>
<form>
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" id="password" name="pwd" readonly autocomplete="new-password"/></label><br/>
<input type="submit">
</form>
<script>
document.getElementById('password').onfocus = function() {
document.getElementById('password').removeAttribute('readonly');
};
</script>
</html>
As you didn't reply to my comments I suppose that my assumption was correct. So I'll post the comments as the answer:
I don't have Chrome 79 and Firefox 71. I've tested it on Chrome 85 and FF 80 on Ubuntu.
It works as intended.
I assume that by
should NOT use that info to autocomplete the password - yet, it does.
you mean that:
When the password field gets focus browsers show a drop-down list with an option to fill in the field with previously stored password.
This looks to you as
[browsers] should NOT use that info to autocomplete the password.
[...] the behavior seems to have changed or is ill-documented.
But actually this is exactly the intended behavior.
From this (the previous paragraph on the same page you've linked) you can see the reason:
Even without a master password, in-browser password management is generally seen as a net gain for security. Since users do not have to remember passwords that the browser stores for them, they are able to choose stronger passwords than they would otherwise.
For this reason, many modern browsers do not support autocomplete="off" for login fields
If a site sets autocomplete="off" for username and password fields, then the browser still offers to remember this login, and if the user agrees, the browser will autofill those fields the next time the user visits the page.
Of course, it's about autocomplete="off" not about autocomplete="new-password"
Let's read further
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 autofilling of password fields, you can use autocomplete="new-password".
This is a hint, which browsers are not required to comply with. However modern browsers have stopped autofilling <input> elements with autocomplete="new-password" for this very reason.
From this:
autofilling is not the same thing as suggestions
browser CAN, but not SHOULD prevent autofilling
autocomplete="new-password" prevents autofilling not suggestions
So when you set autocomplete="new-password" browsers stop filling these fields but continue to show drop-downs with suggestions.
There is nothing about autocomplete="new-password" stopping suggestions, and there is a clear reason why suggestions are always available.
Yes, maybe the wording is a little bit confusing, but follows the behavior to the word.
About the history and use-cases behind this feature you can read here
And now about use-cases... why do you need this?
If several users have access to the computer, disabling suggestions won't stop them from logging in to a site as a different user. They can see passwords in the settings and use them. To prevent this, users must have different accounts on the computer.
If you don't want them to use old password in place of a new-password, then, yes, it will complicate things a little (which is actually bad - when things are complicated users tend to use poor passwords), but won't stop them from remembering the old password or, again, from getting it from the settings. For that you need to check if the password is really new in your code.
If you want to prevent suggestions anyway, then you can use hacks from #Moayad.AlMoghrabi's answer (I haven't tested them, but I believe he did). But without knowing your use case, I would strongly recommend against it. It breaks user experience and does not boost security. On the contrary, lessens it.
I know what your talking about, and in your case you should leave it. Security is a major issue, obviously, and the answers above are absolutely correct. There are work-arounds though, like using read-only which has been mentioned, I would try to achieve your goal using read-only, however; read-only does not always give disired results. A less favorable, and I feel like someone is going to lecture me hard for answering with this, but I feel as a developer, you need all the information, what you do with that information is your decision.
PSEUDO ELEMENTS
Googles chrome and Safari, imho, are the most annoying when it comes to auto-fill. To get around this, one option is to create HTML pseudo elements for the pwd and login inputs. Hide them using CSS display property set to none. Since google will only auto-fill one password-input element, and one username text-input element, this work around tricks Google into auto-filling elements that are not displayed.
The Problem With This Method
The problem with this method is that you need to make sure that you validate the data on the backend, and even more so, you need to make-sure your using the right elements to pull data from for your database. The worst problem is that as things update this work-around will guaranteed, at some-point, either stop working and the elements will one-day show without you knowing, making not developers using your site very confused, or confuse the browser in ways we cannot predict because the changes have not come. Its somthing you always have to be aware of. I use to use this method alot, but I stopped because people who know a lot more than I do, really did not like me doing it.
End Note:
Every browser is programed to present forms differently. Some browsers, especially mobile versions and safari actually change the physical look of your elements, which IMO is uncalled for. At the same time though they do this to try and deliver web standards to boost security and make things easier to use for people like my non tech-savvy 85 year-old Grandma. As noted, browser do things differently, and people can choose different browsers, selecting the one they want. Auto-fill is part of the experience that users get from a browser, and is a major deciding factor on which browser people choose. If you use work around, like the one I explained you change that browser experience, and give the user what you want, but it might not be what they want.
If you do decide to use, or at-least try this method, please let me know how it goes, its a pretty easy hack/work-around, and I have got pretty good at tricking browsers and can help you if my example doesn't work for you. Let me know what backend your using and browsers your experimenting with and I will get you working code, but first think about what you really want. Sometimes we have to settle, especially if it is in the best interest of the clients experience using the sites/apps we build, or to improve the security of, not just the client but, our servers and our self.
body{
width: 100vw;
padding: 0;
margin: 0;
background-color: #ddb;
overflow-x: hidden;
}
#login-psuedo{
display: none;
}
#pwd-psuedo{
display: none;
}
<html>
<head>
<style></style>
</head>
<body>
<form>
<input id="login-psuedo" type="text" name="login-psuedo"/>
<input id="pwd-psuedo" type="password" name="pwd-psuedo" autocomplete="new-password"/>
<br />
<label>Login <input type="text" name="login"/></label></br>
<label>New Password <input type="password" name="pwd" autocomplete="new-password"/></label>
<br>
<br>
<input type="submit" value="Submit">
</form>
</html>
I know quite an old question.
But adding autocomplete="off" in the form tag might help (I know not in all cases - as some fields might require autocomplete fills - Specially when you are testing)
works for firefox now* (*98.0.2 (64-bit))

Disable autofill in Chrome 63 [duplicate]

This question already has answers here:
Disabling Chrome Autofill
(68 answers)
Closed 4 years ago.
I just updated my browser to Chrome Version 63.0.3239.84 (Official Build) (64-bit).
I then proceeded to go on my website, where I have a input box with autocomplete='off', yet I still get the following:
(You can see my inbuilt suggestion dropdown below it)
This never used to be the case. Nothing else has changed!
Why is this happening? Is this a bug in the new version of chrome? I have tried all other suggestions like autocomplete="false" or applying autocomplete=off to the form too. I have even tried to apply these with jquery after the page has loaded but also no luck.
I have tested this on multiple machines with the newest version of chrome on different operating systems. The issue persists.
Update Apr 2021:
Chrome and Firefox support autocomplete="off"
Safari continues to ignore autocomplete="off" and as far as I know there's no good solution fore Safari except to obfuscate the field name.
Update Feb 2018:
Thanks to #JamesNisbet for pointing this out in the comments.
According to the Chrome team, autocomplete="off" and autocomplete="false" will be ignored moving forward. This is not a temporary regression in Chrome.
Chrome will attempt to autofill any form fields that follow the WHATWG standard on autocomplete. With one exception, they ignore "off" and "false" values.
In summary, to disable autofill, use the autocomplete attribute with a value that is not on the WHATWG list.
Make your case why you think autocomplete="off" should not be ignored by Chrome in this Chromium thread.
Looks like a possible regression in Chrome 63. In Chrome's original autofill documentation:
In the past, many developers would add autocomplete="off" to their form fields to prevent the browser from performing any kind of autocomplete functionality. While Chrome will still respect this tag for autocomplete data, it will not respect it for autofill data. So when should you use autocomplete="off"? One example is when you've implemented your own version of autocomplete for search.
https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill
They do make a distinction between autocomplete and autofill, although it's not clear they are different.
Chrome, Safari, and Edge are all attempting to implement autofill but there is no clear standard. They look at the name attribute rather than an explicit, standardized attribute.
For now autocomplete="something-new" is a good workaround, although syntactically it makes no sense. This seems to work because the browser can't understand it.
We tried autocomplete="false" and autocomplete="off", neither work. But something Chrome doesn't understand, like autocomplete="disabled", does seem to work. Strange!
Update: this is working as of Chrome 72.
2019 It seems autocomplete="disabled" works again as of Chrome 72.
SINCE A LOT OF PEOPLE HAVE BEEN DOWNVOTING WITHOUT READING THE COMMENTS:
THIS NO LONGER WORKS IN CHROME AS OF 2018 / CHROME 63+
relevant: https://bugs.chromium.org/p/chromium/issues/detail?id=587466
Having autocomplete="false" instead of autocomplete="off" works, you can read more from the Chrome team as to why they did it
here:
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
https://bugs.chromium.org/p/chromium/issues/detail?id=468153
https://groups.google.com/a/chromium.org/forum/#!topic/chromium-dev/zhhj7hCip5c
https://developers.google.com/web/updates/2015/06/checkout-faster-with-autofill
Looks like chrome looks for the closest "label" html tag to the input, and analyzes the label's value/html to affect the input's autofill.
The cleanest workaround I found to disable the input's autofill was this:
<label for="">Country</label>
<label for="" style="display: none;">hidden label to mislead chrome autocomplete</label>
<input ... />
I've managed to get a working "hack" in Chrome Version 65.0.3325.162 (Official Build) (64-bit).
I have to render an input field - hidden so it doesn't affect my page:
<input style="display:none;"/>
Then I render my password input field:
<input type="password" autocomplete="new-password" />
So my form ends up looking like:
<form>
<input style="display:none;" />
<input type="password" autocomplete="new-password" />
<input type="submit" />
</form>
Importantly, you cannot add a name or an id attribute to your password type input element, and you must have autocomplete="new-password"
After Chrome 63 it looks like they changed it to autocomplete="disabled"
I recommend you get a browser detecting library and for the rest of it use autocomplete="off"
As Chrome is never going to work properly and/or keeps changing its mind (I know its not human) the simplest solution to ensure autofill/autocomplete stops is to do the following on any inputs you dont want autofilled:
<input type='text' readonly onfocus="this.removeAttribute('readonly');" value=''/>
For Angular users, Since the autocomplete = 'off' ignore by new chrome versions, chrome developer suggests autocomplete= 'false | random-string', so the google chrome/modern browsers have 2 type of users helpers -
autocomplete='off' (which prevents last cached suggestions).
autocomplete = 'false | random-string' (which prevents autofill setting, since the 'random-string' is not known by the browser).
so what to do, in case of disabling both the annoying suggestions? Here is the trick:-
add autocomplete = 'off' in every input fields. (or simple Jquery).
$("input").attr('autocomplete', 'off');
Remove the <form name='form-name'> tag from HTML code and add ng-form = 'form-name' in your <div> container. adding ng-form="form-name" will also retain all your validations.
I feel terrible how different browsers use different options in a same functionality.
If it's chrome, use autocomplete="disabled" which handles both autocomplete and address based autofill (two separate things):
element.autocomplete = isGoogleChrome() ? 'disabled' : 'off';
You can get some insight on how to writ isGoogleChrome() from here
JavaScript: How to find out if the user browser is Chrome?
Current working solution using JQuery:
Removed name and id from the input I don't want autofill on and added an identifying class. I then created a hidden input with the field name and id I want. Then on form submit I copy the value from the field with no id and no name (finding it by my identifying class), into the hidden field with the name and id.
HTML
<form id="myform">
<input class="identifyingclass" value="">
<input class="hidden" id="city" name="city" value="">
<button type="submit">Submit</button>
</form>
Javascript
$('#myform').on('submit', function(e) {
$("#city").val($('.identifyingclass').val());
});
I reckon this should work as I don't see autofill latching on to anything other than an id or name.
Every answer I could find did not work for me. The most irritating part about my situation was how Android populated the notes field with a login name, resulting in erroneous notes being entered into the database.
I thought about how typing into the text input clears the Android autofill and the below trick worked. Note that simply clearing the value did not remove the autocomplete, I had to set the field's value. Immediately clearing the value after setting a value also did not work. The delay is needed for Android chrome to see a change and remove the filled in value.
Bonus: doing this action on the notes field caused Android to empty the other autocompleted elements in my form.
<script src="/js/jquery-1.12.1.min.js"></script>
<script>
$(function () {
$('#notes').val('--');
setTimeout(
function(){ $('#notes').val(''); }
, 2000
);
});
</script>
<input type='text' id='notes' name='notes' maxlength='250' size='17'>
The function setTimeout( callback, msec ) is javascript, thus a programmer could implement this without using jQuery.
I fixed this on my site by replacing the offending input element with
<p class="input" contenteditable="true"> </p>
and using jQuery to populate a hidden field prior to submission.
But this is a truly awful hack made necessary by a bad decision at Chromium.
I usually do this to hide the autofill icon:
<div style="width: 0; overflow:hidden;">
<input type="text" />
</div>
As Chrome will put the autofill icon on the first writable text field, the icon is placed on the hidden input field.
Note: Making the input field hidden-type or setting its display to 'none' doesn't seem to work.
autocomplete="off" works in the current Chrome 68 as well as in Chrome 63.
Demo.
Try to remove the "Id" of the input.
That's how i fixed it.

Disable input text suggestions in Edge?

I have built a textbox dropdown AngularJS component which works great in Chrome, Firefox, Safari and Internet Explorer.
A feature of this component is that you type in a string, and then can use the up/down arrow keys to scroll through suggestions.
In Microsoft Edge, as soon as you hit the down arrow, the following text is added to the input box:
briefly explain your changes (corrected spelling, fixed grammar, improved formatting)
Is there anything I can do client side to stop this from happening?
<form>
<input type="text" />
</form>
To demonstrate this, run the above snipper, type something into the textbox and hit the down arrow twice on Edge. I want this to not happen, as it is breaking my autocomplete!
Thanks
If I understand correctly, you are having an issue with the autocomplete feature. Simple add "autocomplete='off'" to your input and that should disable the feature.
<input type="text" autocomplete="off"/>
Unfortunately, none of the above suggestions worked for me in latest Edge. However, this solution does:
<input type="text" autocomplete="off" list="autocompleteOff"
id="fieldId" name="fieldname" placeholder="Placeholder here" />
This forces Edge to find a data lookup list called autocompleteOff which doesn't exist. Works a treat for me.
Added advantage is that it's pure HTML, no CSS or JS required.
2021 update:
Another solution which works very well for me is to add the readonly attribute to the field and then remove the tag using JQuery after a short delay of a few ms. The readonly attributes causes Edge (and others) to ignore the field.
For anyone experiencing autofill ignoring the autocomplete="off" on Edge 105+, you can use aria-autocomplete="none" alongside, which will prevent autofill from showing up (Tested in macOS 12.5 but should work in other platforms)
From Mozilla:
You can set the autocomplete on the actual form tag <form autocomplete='off' ... >...</form> which will work for the entire form, or on individual <input type='text' /> tags.
In my experience on IE 11 and Edge putting it on the form works but individual tags does not work. I tried testing on Chrome but the fields were already not autocompleting.
Please read the full Article for more detailed information.
NOTE
Most browsers disregard this for login fields.
if you want to remove autocomplete at the input in chrome when you use autocomplete="off" also you must remove id, if you don't remove id on your input, autocomplete will not work!
simple example:
<input type="text" autocomplete="off" list="autocompleteOff"
name="fieldname" placeholder="Placeholder here" />
you can handle your input with name ;) , that work for me fine.
<input type="text" autocomplete="new-password" />
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 autofilling of password fields, you can use autocomplete="new-password"
MDN reference
It works also for non-password fields.
if you need it app/site-wide you can use jquery:
$('input').attr('autocomplete','off');
Or if you're like me and using Angular+ui-router you might try the following:
In your index.html add the following script:
<script type="text/javascript">
setTimeout(function() {
$('input').attr('autocomplete', 'off');
}, 2000);
</script>
Then to cover state changes, add the following to your 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.
This worked for Edge & Chrome (not a login form tho, not sure if that makes a difference)
autocomplete="somerandomstring"
https://gist.github.com/niksumeiko/360164708c3b326bd1c8#gistcomment-2367048
Just autocomplete="off" list="autocompleteOff" in your input and work done !
autocomplete="off" doesn't work since yesterday (edge 105.0.1343.25).
Looks like a bug to me. Hopefully, they will fix it soon.
in edge worked for me
`autocomplete="false" readonly onfocus="this.removeAttribute('readonly');" /
`according to this https://stackoverflow.com/a/30344707/14913109

Why is Chrome showing a "Please Fill Out this Field" tooltip on empty fields?

I was contacted by my client saying that users complaint saying that some fields now show a tooltip with a message "Please Fill out This Field". I couldn't believe what I heard... but the client is right - using latest Chrome version some fields show a browser tooltip with this message even side by side with my validators!
What's the problem? What am I missing?
Thanks.
EDIT:
The HTML generated by my user control is as follows:
<input name="tbMontante" type="text" maxlength="8" size="10" tbMontante" class="Montantetextfield"
FieldName="Montante"
Required="True"
AllowDecimalValues="True"
/>
EDIT:
My doctype is as follows:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Should my browser use HTML 5 to parse it?
Are you using the HTML5 required attribute?
That will cause Chrome 10 to display a balloon prompting the user to fill out the field.
https://www.w3.org/TR/html5/sec-forms.html#element-attrdef-form-novalidate
You can disable the validation in the form.
Put novalidate="novalidate" on <form> tag.
<form novalidate="novalidate">
...
</form>
In XHTML, attribute minimization is forbidden, and the novalidate
attribute must be defined as <form novalidate="novalidate">.
http://www.w3schools.com/tags/att_form_novalidate.asp
To stop that Html5 popup/balloon in Web-kit browser use following CSS
::-webkit-validation-bubble-message { display: none; }
As I mentioned in your other question:
The problem to do with that fact, that you invented your own non-standard attributes (which you shouldn't have done in the first place), and now new standardized attributes (or attributes in the process of being standardized) are colliding with them.
The proper solution is to completely remove your invented attributes and replace them with
something sensible, for example classes (class="Montantetextfield fieldname-Montante required allow-decimal-values"), or store them in JavaScript:
var validationData = {
"Montante": {fieldname: "Montante", required: true, allowDecimalValues: true}
}
If the proper solution isn't viable, you'll have to rename them. In that case you should use the prefix data-... because that is reserved by HTML5 for such purposes, and it's less likely to collide with something - but it still could, so you should seriously consider the first solution - even it is more work to change.
You need to add the attribute "formnovalidate" to the control that is triggering the browser validation, e.g.:
<input type="image" id="fblogin" formnovalidate src="/images/facebook_connect.png">
If you have an html form containing one or more fields with "required" attributes, Chrome (on last versions) will validate these fields before submitting the form and, if they are not filled, some tooltips will be shown to the users to help them getting the form submitted (I.e. "please fill out this field").
To avoid this browser built-in validation in forms you can use "novalidate" attribute on your form tag.
This form won't be validated by browser:
<form id="form-id" novalidate>
<input id="input-id" type="text" required>
<input id="submit-button" type="submit">
</form>
In Chrome (v.56 is what I'm using but I AFAIK this applies generally) you can set title=" " (a single space) and the automatic title text will be overridden and nothing displayed. (If you try to make it just an empty string, though, it will treat it as if it isn't set and add that automatic tooltip text you've been getting).
I haven't tested this in other browsers, because I found it whilst making a Google Chrome Extension. I'm sure once I port things to other browsers, though, I'll see if it works in them (if even necessary), too.
Hey, we just did a global find-replace, changing Required=" to jRequired=". Then you just change it in the jquery code as well (jquery_helper.js -> Function ValidateControls). Now our validation continues as before and Chrome leaves us alone! :)

Is there any pure-html attribute to specify which element should be focused on load

And if there isn't, is there a good reason why?
This is coming as a part of HTML 5, so the lack of it in prior version is probably more of an oversight or a case of there being other options lowering the priority.
If you're curious, the syntax will be something like:
<input type="text" name="abc" value="" autofocus>
By the standard, it must only be declared once on a page.
In the meanwhile, with the state of the nation, you can only really do it with script in the onload event. The easiest way, is to assign the default element on the page a consistent id (call it 'autofocus') and then always set it like:
var a_focus = document.getElementById('autofocus');
if(a_focus) a_focus.focus();
Hope that helps.
Is TABINDEX=0 not working for you?
EDIT:
Sorry - hurried my answer. TABINDEX=0 will work only if the user hits the "TAB" key. Sorry about that. The following will set focus properly on load. Tested in latest IE, FF, Opera, Safari, & Chrome.
<form>
<input id="first" tabindex="1" /><br/>
<input id="second" tabindex="2" />
<script>
document.getElementById("first").focus();
</script>
</form>
There isn't. There's not really a good reason, other than everyone grew used to using focus() instead. (Unfortunately focus() has drawbacks if the whole page doesn't load and focus straight away.)
I would love to see a both default-focus and default-submit-button designation available in HTML, but the browser folk don't seem to be interested. Edit: as John said, this is now in the HTML5 draft, though there's no implementation yet and HTML5 is far from finalised. We'll see!
No.
And probably no good reason; everything seems obvious in hindsight.