My fields complete itselves - html

good afternoon,
i'm, at the moment, programming a web site with Symfony2.
I use a form and into this form there are some input type="text"
and two input type="password".
I'm encountering a problem using this form, indeed the password and the neighboor input complete itselves, by using my own name and my password.
The thing is that those inputs shouldn't be allowed to do this, a thing even stranger is that the input in which my name is put is not even a login input, it is called "inpCity".
I'm not sure if what i'm saying is clear for you, but this is really embarassing. I don't want it to autocomplete, i put the autocomplete attribute to off, but it just hides the value of the field.
Any idea about this ?
This is the first time it happens, while i used to create 3 others website (without Symfony)
PS : sorry for my english, this is not my main language

I think it's built-in feature of browser but suggestions are based on the name of input field.
How did you override getName() of your form type? That "name" is prefixed to you field names, for example:
getName() returns "my_form"
input name is email
your field will be named my_form_email
So, inspect you HTML and find how input name was generated...

Related

Why does HTML input type number accepts the + and - symbol?

Input type number accepts + and -.
I don't want this behavior. How can I prevent this?
<input type="number">
I can type 100+ or 200- or both 300+-
maybe some other special characters are acceptable. I don't want this. Number input should only be Number.
Is it possible User should not even type any special characters?
The default behaviour of a number input is to allow the user to type anything they like and perform validation when the form is submitted.
This is consistent with how all other validation features built into HTML forms work.
If you type 100- then try to submit the form, the submission will fail and an prompt along the lines of "Please type a number" will appear.
If you want validate-as-you-type behaviour then you will need to implement it with JavaScript. This is tricky to pull off well though. For example, you might prevent a user from pasting a string copied from a document like 123,456.12 because it has a comma in it. If you let them paste it they can then edit the comma out.

Usage of HTML private input type

A site I came across uses input type="private" for its password Form field. However, I searched online and it seems that "private" is not one of the defined types (https://www.w3schools.com/html/html_form_input_types.asp)? What does it do and where can I search for more details on this?
As you said, private is not one of the HTML input types. (MDN reference)
Even semantically, the input type 'private' does not make any sense. Input element with unknow type is rendered as text type by default. So here private is just some gibberish for the render.
I guess the site you came across might be doing for any specific use-case - CSS selector like input[type="private"] or with JavaScript - which is not the way to do. As this not standard, it should not be used.
type=private simply isn't one of the default values that the browser would recognize.
However, you're free to give it any type you want, you could give it a type="peanutbutter".
Doesn't matter, cause what matters is: now you can call that input type with jquery or something by doing input[type=peanutbutter] to select all inputfields with that specific type using javascript, jquery or css.
My guess is that type=private doesn't exist, but it's simply something used by that company to manipulate the inputfields.

What is the difference between null and ""

I am currently trying to understand the jsp codes of another guy but I am having trouble with the following codes:
if( request.getParameter("username")!=null &&
!request.getParameter("username").equals(""))
The username is the field a user fills on an HTML form. The codes after these codes saves the data the user fills in into strings which will be later used for other purposes.
My question is what is the purpose of the !request.getParameter("username").equals("") code part in the above?
Has request.getParameter("username")!=null part of the code not already tested whether the user enters information into the input field of the HTML form or not?
Regards
If you reveive a request like
http://.../yourservlet
then the parameter value will be null, since no parameter named username is passed at all.
If you reveive a request like
http://.../yourservlet?username=
then the parameter value will be the empty string, since the parameter is passed, but its value is the empty string.
What you'll receive depends on the HTML, and on what the user actually does (he could type the URL manually in the address bar, for example). The code makes sure both cases are handled in the same way. Let's imagine some JavaScript in the page disabled the input field or removes it from the DOM when some checkbox is checked. In that case, the parameter won't be sent at all.
Has request.getParameter("username")!=null part of the code not already tested whether the user enters information into the input field of the HTML form or not?
No. A text input in a HTML form will always send a value. If nothing has been typed into it, then that value will be "".

How does the vcard_name attribute work re: input fields?

Can anyone explain how the (IE) vcard_name attribute works as applied to HTML input fields (see below)?
<input name="foo" vcard_name="bar">
I've read Microsoft's documentation but am still unclear. In the example above, does the inclusion of the vcard_name attribute mean that AutoComplete suggestions will be drawn exclusively from the Profile Assistant? Or will suggestions be drawn from both the Profile Assistant and the standard autocompletion store?
Also, does the inclusion of the vcard_name attribute mean that the user's input will be saved in the Profile Assistant when the form is submitted?
Hope this will help you.
Thanks
How It Works (Basically)
When you enter information into a form and submit it, Internet Explorer sets up what's known as a vCard. The reason the function is so successful is that Web authors tend to use the same NAME attributes for many form elements across pages.
For instance, I'll bet you've filled out a ton of forms that ask for your name. Allow me to demonstrate. Type the first few letters of your name in the text box just below. If you're using IE 5.0 or above, I'll bet your name appears as a choice you can make. Try it in the e-mail box, too. I'll bet you get your e-mail as a choice. It won't work for everyone, but I'll bet I get the majority of you:
If it worked for you, and I'll bet it did, you're probably wondering how I knew each item would come up. Well, first off, here's the code from the form above:
<FORM>
Name: <INPUT TYPE="text" NAME="name">
E-mail: <INPUT TYPE="text" NAME="email">
</FORM>
It's the NAME attribute that does the trick. I'm basically making a guess that sometime, somewhere, you filled out a form that asked for your name and e-mail address. In addition, I am guessing that the form used the NAME attributes "name" and "email". They are very common.
If it worked, then you have a couple of vCards on your system named "VCARD_NAME" and "VCARD_EMAIL". When you filled out the other form and submitted it, the card was created. Now, from that point on, whenever you run into a form that has an element with a NAME attribute set to "name" or "email," the text from that vCard will be suggested to you.
Let me attempt to prove that point again. Below is a form that looks exactly like the one above, except the first text box has its NAME attribute set to "griswald" and the second set to "ookook". Go ahead, try to put your name and email in. You'll get no help from AutoComplete.
You didn't get any help because you don't have VCARD_GRISWALD or VCARD_OOKOOK on your computer. Luckily, I didn't give you the opportunity to submit the form, or you would have.
Basically, the *vcard_name* attribute overrides the name attribute. It tells the browser to use the vcard_name value passed as the schema to look for AutoComplete suggestions. If this is not provided, the name attribute is used.
Specifies the vCard type to use for the Autocomplete box. Setting the
value of the vCard_name attribute causes the contents of the
Autocomplete window to depend on the value of this attribute only,
regardless of the value of the name attribute. If the value of the
vCard_name attribute is not specified, the contents of the
Autocomplete window depend on the value of the name attribute.
Source : http://help.dottoro.com/lhwgvcmt.php

Ways to remove the autocomplete of an input box

I need a text input field which does not use the autocomplete function - If a user has submitted the form before, his previous submissions should -not- appear as he types into the form again, even if he is typing the same thing again. As far as I can tell, there are a few ways to do this:
1. <form autocomplete="off">
However, I believe this is a proprietary tag, and I am not sure how compatible it is across browsers
2. Give the input field a random 'name'
One could even use JS to set the name back to an expected value before submission. However, if the user does not have JS installed, you'd need another hidden input with the name - and the php code on the other side gets messy fast.
Do you know of any other ways? Is one of these ways the "accepted" way? Comments?
Thanks,
Mala
Lookie here: Is there a W3C valid way to disable autocomplete in a HTML form?
Stick with the random name. You can do it simply enough server and client and you meet your no-js requirement.
You can store the original and changed name in a $_SESSION variable before outputting the form, and after the user submits, just get the name from there:
$random_name = md5('original_name' . time());
$_SESSION['original_name'] = $random_name;
...output form...
And after submitting you can easily get the value from $_POST using the $_SESSION variable:
$field_value = $_POST[$_SESSION['original_name']];
Just be sure that you have sessions available by calling session_start() before any processing.
Autocomplete is something that browsers decided to do on their own, so there’s certainly no spec document to look at.