How can I avoid browser prepopulating fields in my registration form? - html

autocomplete="off" is not what I am after. Basically, on my registration form there are fields "phone" and "password" placed one above the other. (see screenshot)
The "phone" field gets, annoyingly, prepopulated with a username, as I guess what the browser is doing - the browser finds a field of type password and assumes the text input field just before it is a username field. The effect is this:
Why I am not interested in the non-standard autocomplete attribute for the phone field, is that I do want user to be able to fill this form as easily as possible and if they have previously entered their phone number on other sites (into fields called "phone") they could benefit from this showing up as they start typing into the field. That's why I don't want to turn autocomplete off altogether.
I was thinking more in the direction of reorganizing the fields somehow to avoid this behaviour. Or some way of telling the browser that the field above the password field has nothing to do with it, or that the password field is not used for authentication purposes. Somehow mark it as that. Or inject some invisible element inbetween these two fields?
Any ideas?
Markup used:
<input id="phone" name="phone" type="text" value="" maxlength="30">
<input id="newPassword" name="newPassword" type="password" value="" maxlength="20">
I am getting this behaviour on Chrome, FF, (not sure about IE, got an archaic version of that on my machine, don't even want to start worrying about IE yet.)

Most password managers will search the first password field, and the closest text field before it.
So all you have to do is add invisible text and password fields (display:none) above "new password".
Firefox tries to interpret 3 password fields as a "change password" action, so if you don't want that you should be safe adding yet another invisible password field.

I had a similar issue with the set password field. Try
<input type="password" autocomplete="new-password">
From MDN input documentation:
autocomplete
This attribute indicates whether the value of the control can be automatically completed by the browser.
Possible values are:
....new-password: A new password (e.g. when creating an account or changing a password)
For the phone number issue, I set this and it stopped autocompleting the username there.
<input type="tel">

A home number cannot be 30 characters, this is probably why the browser is assuming it could be a username or login email due to the size. Change it to something real and see what happens.
Also, consider having 3 field for phone number, area code, prefix, suffix. Once a certain number of digits are filled, you can auto focus using JavaScript the next phone segment field so it's easier for user.
Have you also tried changing positions of fields? What's happened?
Also, just to make sure, you can turn off auto complete on a particular item during registration without worrying that it will be off during login (cuz it won't) unless you turned it off for the login fields as well, and of course you have no need to.
Also, delete your unused saved form auto complete stuff, could just be a local issue with your version, you may have entered a bad value one day in one of the browsers, and then you installed the other browser (chrome or FF), and then the newly installed browser copied the rules exactly as they were from your original browser.... So, you end up thinking it's a global issue with your form, simply because of one bad entry and because your second installed browser copied and replicated the bad entry rule from your first browser, making it look like a real, universal problem to you, get me? So try the browsers InPrivate modes, or try the browsers from a different installation or a different computer, or from a virtualpc instance you may have.
Otherwise, export all your setting from your browsers and uninstall both browsers, then reinstall from scratch FF and chrome, then test your webpage, then feel free to import your exported settings back.
Also, test on IE even if it is for the insight it may give you, know what I mean?
Hope this helps, let me know how you get on, and if you have any other questions.
UPDATE:
Given the method you've chosen, what you should be able to do is, when rendering the phone field, add a value=" " attribute into the input tag, instead of using JavaScript. This should prevent the pre-filling from occuring without needing to use javascript. Now, if you want to go one step further, you can do this:
During the OnLoad Event of when page loads, check the phone field using JavaScript, and if the value equals one space (" ") then overwrite it with an empty string using JavaScript once onLoad is triggered. Or, if the browser is still prefilling (i doubt it will but if it is) you can delay this check by a few hundred milliseconds and run the javascript a few hundred milliseconds after the page has loaded, or tie it to all or some of the input fields onFocus events, so as soon as any of the fields gain focus, you do the "does phone.value equals one space character (" ") and if it does, overwrite it with and empty string, i'm even more certain the browser isn't going to jump in and hijack that field in this situation. Although, as mentioned, even if you do this onLoad, i doubt the browser will hijack your field, as the pages/javascript onload occurs AFTER the browsers internal onLoad (DocumentComplete) event occurs, and worst case scenario, you can do the few hundred millisecond lag or onFocus method, but i doubt you will need these.
Let me know how it goes.

I tried disabling the input fields type=text& type=password after loading of the DOM then enabled all the disabled fields after certain milliseconds lets say 100. It seems to be working for me.
Try :
$(document).ready(function()
{
$("input[type=text],input[type=password]").prop('disabled','disabled');
$("body").delay(10,function(){
$("input[type=text],input[type=password]").prop('disabled','');
});
});

Related

How do browsers decide what data to use for auto-fill on each input?

I've seen other questions asking how auto-fill works, but the answers all explain how to make it work, which is not what I want. I want to stop it from working. And I also realize that there are many questions out there asking that specific thing, but the answer is always to set autocomplete=off, which we all know is useless because browsers don't honour it.
And besides that, my question is a little bit different because what I'm really asking is how the browser decides which inputs to populate with what data, because I'm hoping with that knowledge I can prevent the problem I'm having.
Specifically the issue I'm having is that every time I open up my "change password" page, my search input is automatically being filled with the username. I'm trying to understand why it's doing that so that I can prevent it.
My input does not have a name or a label or an autocomplete attribute. It's just very simply as shown here. So in what universe does it make sense for a browser to find a field with the id "searchinput" and think that it makes sense to auto-fill it with a username?
<input type=text id=searchinput placeholder='Search'>
Also, on the change password page, the first of the two password fields is automatically filled in (presumably with the matching password but I can't see it because it's all circles). So why are these browsers auto-filling my search input with the username and how can I prevent it?
To explain a bit further what my code is doing: When the user selects "change password" from the menu, I load my change password page into a div (using jquery load) on the existing page and slide it down to cover most of the browser window (minus the header and menu), which means whatever page they're currently on is still there underneath, and that's also why my search input is still visible. The auto-fill happens as soon as I load my change password page.
In my particular case, the reason the input field was being auto-populated with the username is because Chrome auto-fills the first password field it finds (and you can't stop it), and then also auto-fills with the user name whatever input field comes before the password field in the DOM, regardless of what the name, id, or purpose of that field might be. In my case, it was the search input.
So to get around this I had to create another input just before the new password input and hide it out of view with absolute positioning so that Chrome will fill this useless field instead of my search input. Sigh.
<input type=text style='width:0px;position:absolute;right:-100px'>
I also added an "out of view" password field so that Chrome will auto-fill this field instead and not the first password field in my form.
<input type=password style='width:0px;position:absolute;right:-100px'>

Disable autocomplete on regular text input, but allow back>forward saving of value

I have an html input field, type text, that is not a password or any type of sensitive information. It is used frequently to put in dollar values. Autocomplete by a browser is annoying because it comes up every time, gets in the way (for some fields this system has its own autocomplete so that's crazy and I disable it there too, though not on this one). The field just requires typing in a dollar value which is different almost every time so autocomplete isn't very useful.
I used the autocomplete="off" on this field.
Then the users mentioned that now when they hit back in their browser, then forward, the value is cleared out. I traced it to this, that's indeed what it does. Other fields keep their values just fine as dictated by the browser's behavior.
Now how to I allow this saving of the value, but disallow the actual autocomplete? This change that came along with autocomplete is unwanted for me. I also don't see it mentioned at all on the w3schools page for autocomplete, but it does it in Firefox and Chrome.
Thanks for any suggestions. The simple thing would be to just allow autocomplete again so I might end up doing that :/
You could keep autocomplete off but create a local storage value that persists that particular fields last value, you could trigger when the value changes. When the page is loaded you would then have a function that checks to see if the value is in local storage and if so populate that field.
Here is an article on using local storage - http://www.thomashardy.me.uk/using-html5-localstorage-on-a-form

Is the autocomplete only about Back and Forward button and their history, but not about history, bookmark, revisit, or suggestion?

I found the specs for the HTML autocomplete attribute here:
http://www.w3.org/Submission/web-forms2/#the-autocomplete
But it doesn't mention when it is applied to. It seems like when it is on, then that means a user can press the Back and Forward button of the browser and the data will be kept in the input text box, or if the user chooses a history item using the Back and Forward button area. And when it is off, that means the data should not be kept in the input box.
And it is not about:
the history window bringing a page back (after clicking on a history item)
any bookmark bringing a page back
typing in the same URL in the browser
suggestion, such as when a user typed in "macbook" before, now the user types in "mac", and it tries to suggest "macbook" either just inside the input box (but with the "book" part highlighted so the user can keep on typing, or by showing an extra pop up box down under the input text box, for a list of suggestions.
since any time a user exits the browser, for what is known as a "session end", then by (1) to (4) above, there is no way that the data will follow the autocomplete="on" behavior.
Is this the exact behavior of autocomplete? (any pointers to a more exact spec will be appreciated).
I made a static webpage and tried it on a Macbook locally using Apache and localhost://try.html, but the basic behavior can be tested here:
http://jsfiddle.net/jzNTM/3/
http://jsfiddle.net/jzNTM/4/
Autocomplete: Should the browser remember answers for the given field. (number 4 in your list)
autocomplete="on" is the default
Say you have a social-security-number input field
<input name="ssn" placeholder="xxx-xx-xxxx" />
If I enter 555-55-5555 the browser will remember that answer
If I (or anyone else) comes back to the form later and start to type "5" into the field, the browser will auto-complete / auto-suggest "555-55-5555"
For something sensative like a SSN, this is probably most undesireable. (great way to harvest personal data from a public computer)
Adding autocomplete="off" to the input (or form) will prevent the browser from remembering entered values
<input name="ssn" placeholder="xxx-xx-xxxx" autocomplete="off" />

Force a numeric keyboard but allow punctuation: HTML5, mobile Safari

I'm building an HTML page to be viewed in mobile Safari [and other platforms]. The page lets the user specify several start and end times. They have to input at least two times, and possibly more depending on their situation.
I want the user to be able to input their times as numbers and punctuation using the numeric-SHIFT mode keyboard, i.e. the user will see fields like this:
And they'll get the numeric-SHIFT keyboard when they focus into the field:
Won't work:
<input type="time"> (and related datetime types) is not an option. The scrolly-wheel is unacceptable from an HCI perspective, particularly for repeated entries.
<input type="number"> does the right thing at first. It triggers the keyboard in numeric-SHIFT mode, i.e. the numeric & punctuation portions are visible by default. But when you exit the field, mobile Safari strips out punctuation (i.e. the colon). I tried turning off validation in the form using novalidate but that didn't work.
<input type="text" pattern="[0-9]*"> triggers the telephone keyboard with no way to enter the colon character.
I may just need a different RegExp in the PATTERN attribute, but each one I've tried triggers the normal alpha keyboard, and the user has to hit a key to get to the numeric-SHIFT keypad.
Can anyone tell me how to force the keyboard into numeric-SHIFT display without triggering harsh validation rules on the user's input?
Take a look at jQuery Mobile DateBox. here. Its possible you might want to rethink text input here. Maybe you want to go with a picker. Sencha Touch also has a DatePicker. I wrote an extension that implements a timepicker object. I'll throw it up on GitHub if you need me to.

Firefox remembers wrong details username

I've seen similar questions but nothing that seems to fix the issue I'm having.
I have a 2 step registration form process. On the first page you enter an email address, on the 2nd step you enter a password (and other details).
Firefox offers to remember your details but takes the date of birth field (the last textbox before the password field) as the username. The email address is in a hidden value on the page.
Does anyone know how I can tell Firefox that the email address field is the identifier for the password?
I know I can use autocomplete="off", but we still want the user to remember their password, just with the correct values.
Many thanks
The problem
Firefox takes the field right before the password field to be your username, regardless of the name, id or autocomplete attributes.
The solution
Place your username field and password field next to each other.
Note: Turning off autocomplete tells Firefox to forget the form data, but if this is a registration form Firefox will still ask the user if the credentials should be saved (stored separately from regular form data).
Make sure the name attributes are different for each input.
It may be the case that the browser identifies the first input as username or some equivalent, if no better alternative can be recognised.
EDIT---
Hmm. Well now I'm firing blind, but here's a guess: Firefox might not save form values for hidden inputs, and look for a substitute instead.
Try this: on the second stage, feature the name input as a text input type, not a hidden input type, but hide it with css. Then things might work better.
I've witnessed this behavior in Chrome as well (and customers have reported it in IE), so it's not just a Firefox issue. Namely, as Nelu said, the text field that appears before the password field (that is, a field with name="password") is treated as the login name field, regardless of its name, etc. If there are other form fields that are not "text", they'll be ignored.
For us, the right solution seems to be to avoid giving a field the name of "password" if we don't want that automatic browser behavior to come into play.
I think this is an example of the browser being a wee bit too helpful.