My issue occurs in the following HTML document:
<!doctype html>
Search: <input type="search">
<!-- Display is none when logged in -->
<div style="display: none">
Login:<br>
<input type="email">
<input type="password">
</div>
When I'm not logged in the site it shows the mail/password elements and they get auto-filled correctly. After I'm logged in the page loads again, but now with the elements hidden, but for some reason it then auto-fills the search element with my email address!
When I reveal the login elements using the developer tools it looks like this:
So it's auto-filling hidden elements (which I'm OK with), but for some reason doesn't put my email address in the correct field! How can I stop Chrome from doing this?
This issue is caused by a 'quirk' in Chrome's auto-filling behaviour.
Different websites construct their login elements in different ways, so Chrome has to use a set of heuristics to try to understand login forms. Unfortunately this doesn't always work correctly.
How Chrome determines the credential fields
This is what Chrome is doing to find the login fields:
It finds a password element, now Chrome needs to find the accompanying username element.
To find the username/email element, Chrome scans through some of the elements above the password element.
It selects the element with the highest 'interactability' rating that's nearest to the password field.
Since the email element is hidden it gets a worse interactability score than the search element, so Chrome picks the search element.
Fix
The fix for the issue is simple, you can restrict what elements Chrome will consider to be the username by wrapping those elements in a form. In this case you can just replace the div.
<!doctype html>
Search: <input type="search">
<!-- Display is none when logged in -->
<form style="display: none">
Login:<br>
<input type="email">
<input type="password">
</form>
Chrome will not look outside of the form for the username field, so it always picks the correct element.
Nowadays I always put input elements that belong together inside of a form, even when I don't actually use the form for anything and instead handle the input with JavaScript. It still helps browsers, plugins, and screen readers make better sense of your site.
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))
I have 3 radio button inputs in three separate divs:
<div class="box1">
<input type="radio" name="paymentOption" checked="checked" value="creditcard_on_file" />
<!-- related subfields for that chosen option -->
</div>
<div class="box2">
<input type="radio" name="paymentOption" value="newCard" />
<!-- related subfields for that chosen option -->
</div>
<div class="box3">
<input type="radio" name="paymentOption" value="check" />
<!-- related subfields for that chosen option -->
</div>
on page load, the first one is default selected. and in IE9, when another is clicked, the first one stays selected! whoa.
what can I do to make it behave properly?
it works fine for me.. but if its a compatibility issue. try using JavaScript to clear out the other items.
try this:
How to reset radiobuttons in jQuery so that none is checked
There was a typo in some other html surrounding the given markup. I've learned that IE seems to handle the situations of invalid markup a bit differently that other browsers in that it either duplicates a section, or will hide a section. Since in this case neither of those issues occurred, the markup within incorrect html has misbehaved.
We had the same problem on IE 9.0.8112 64-bit ONLY but for different reasons. We had forgotten to assign a name to associate the inputs together. The funny thing is that this worked on every other browser, because we were using AngularJS's ng-checked to set the radio button state (even the non-64 bit version of IE 9).
Short version:
How can I have my form's button label text differ from the value submitted to the server without using the <button> tag?
Long version:
I wanted to have the text that appeared in a button in a form to be different than the value submitted in the query string. So, I looked around, and came across this approach...
<button name="method" type="submit" value="repackage">Update Config</button>
...and that worked on IE9 on one of my laptops and I was happy. The user saw "Update Config" and the server received method=repackage in the query string.
Then I brought this app to work and ran it on a workstation, also with IE9. But something had gone wrong. The user still saw "Update Config", but the server now received method=Update%20Config in the query string.
So I investigated some more. I found that www.w3schools.com recommmended not using a <button> tag in a form. They say: "If you use the <button> element in an HTML form, different browsers may submit different values. Use <input> to create buttons in an HTML form" in this article. This seems to be what I am experiencing.
So I looked some more, and found lots of conflicting information about the right way to do this. For example here is a Stack Overflow post that asks exactly this question, but the accepted answer is to use the <button> tag. I can say from experience and research that this is not a reliable approach.
For newcomers: With some CSS this works like a charm as of September 2017:
<form>
<label style="padding:5px; cursor:pointer; border:solid 1px; border-color:#ccc">
<input style="display:none" type="submit" name="method" value="repackage">
<span>Update Config</span>
</label>
</form>
If there's no other way try this:
Use an image button, instead of button. An image button will work as ordinary submit button, but you create an image of the desired button text (no one can change your text then).
<input type="image" src="http://images.webestools.com/buttons.php?frm=2&btn_type=31&txt=Update+Config" name="method" value="repackage">
This works as well. Manipulate the appearance using the bootstrap button classes.
<label class="btn btn-primary">
<input class="d-none" type="submit" name="method" value="repackage">
Update Config
</label>
I have made an html wizzard for making order. There are four steps, in each is bunch of radio buttons. I redesigned each radio button label to large button (and hidding the radio input itself). This all work greatly on classic PC. But I've run into problem with mobile device (iPHONE & iPAD, I can't test it on other devices, because I don't have any), which are unable to select the radio button.
I've found only one notice of this problem here on stackoverflow, but the solution published there isn't function either.
The original inspiration comes from apple online store for selecting differnt color of device.
My example code:
<label class="option" for="edit-term-worker">
<input id="edit-term-worker" class="form-radio" type="radio">
<span class="worker-name">Sandra</span>
</label>
It's there need some JS, or I'have some flaw in my code?
Thank you all for your help.
Have you tried this?
<input id="edit-term-worker" class="form-radio" type="radio" />
<label class="option" for="edit-term-worker" onclick="">
<span class="worker-name">Sandra</span>
</label>
EDIT: Added an empty onclick, according to this that should do the trick: HTML <label> command doesn't work in Iphone browser
Note that you shouldn't put the radio button into the label tag, it should be outside.