So if I have a form with a text input, or a select input, I want that box to have a certain value when the page loads. I know you can add,
value="pre defined value"
but when the user erases that and puts in something else, when the form is submitted, is the value that is sent the predefined one or the one that the user changed it to?
The answer to your question is:
The value that is sent is the input that the user typed into the textbox and the value from the select input will be the one you set unless the user uses his browser to change the value(with any developer tools).
On a side note:
If an attacker changes the values then that value will be sent, this is why you must validate all input on server side, and also validate input from hidden, select, checkboxes, etc... elements. Client-side validation is only helpfull to tell the user if he has filled an input with the wrong thing but won't help you against any attacks since they can change the values that are sent with developer tools or a proxy.
Related
I'm working in Access 2010. I have a continuous form containing a list of password records. The password field textbox contains the input mask of input mask = "password". I created a button in my header to unmask the password field, but that affects ALL the records on the form. I'd like only the current record in use to change the input mask to ". I also tried adding an icon next to the password field so it appears on each row, but once again, the change is applied to every row.
I considered the Conditional Format function but that's only designed to change the color of the current record.
Let the button open a popup form (or, even simpler, a message box) revealing the password.
That said, for users' passwords, this should not be an option. The only option should be to reset the password in case a user has forgot it.
I have a form which contains a suggest box. When I click on submit one of the requirement is to not submit the form if the value is not selected from the options.
The problem occurs when we select a value and then clear it and then enter a text not chosen from the options. (Scenario quite possible as some users may not know that value is only to be chosen from the options etc)
In this case the value is still the old one and so the validation does not show any error thus creating an illusion for the user that the text which he entered is accepted as the value.
How do we restrict this?
I am making a signup form for my website. It contains various standard form fields. Such as: name, address, phone number, user name, password, etc.
When I double-click on a field (in Chrome 16), so I can auto-fill my address, I get this message:
This webpage has disabled automatic filling for this form.
I didn't disable it, so how do I enable it? I tried adding autocomplete="on" to the <form> tag, and to (some of) the <input> tags, and that didn't help.
Do I need to add autocomplete="on" to every field? Also, how does the browser know what field is what? Do I need to name the fields something special?
Another question: Is there some kind of onautocomplete event that gets triggered when a form is auto-filled? On my form, when you enter a zip code, it looks in our database (via AJAX) and then gets the state and city (city and state are dropdowns, because zip codes can be for more than one city), and fills them in for you. I was hoping I could have that run after the form was auto-filled.
P.S. I'm using the jQuery form validation plugin, if that matters.
The problem was that the form tag didn't have method="POST" on it.
After Googling the message, I found a bug report, and one of the comments mentioned method="POST".
I added method="POST", and voila! Auto-fill works.
In some cases you may also need to add an action if the form doesn't have one. action="javascript:void(0)" works.
Note: Auto-fill seems to trigger the onchange event.
Note 2: As for how the browser knows what field is what, see this question: How to trigger Autofill in Google Chrome?
The option to turn off autcomplete is normally located in the form tag, see the Developer page from Mozilla here. This should mean that normally removing that attribute should enable it again on a webpage.
Concerning the second part with the AJAX request, I don't think there's a listener for that, but you could add a function that checks the value of the field each x seconds for example, and if it changed you can perform your lookup.
How the reset button (input type="reset") works under the hood?
(I want to extend it so it'll clear the inputs after post in asp.net mvc.)
It makes the browser set the current value of every form control back to its default value (as specified in the HTML, e.g. with the value or selected attributes).
Since it is client side, it cannot be extended with a server side technology like ASP.NET.
If you want to clear inputs after post, then forget reset, just send back the form without any data in it in the HTTP response.
There's a form.reset (docs) method that does the same thing as clicking the form's reset button.
Alternatively you could write some jQuery code that resets the form fields, the topic is covered in this question - Resetting a multi-stage form with jQuery
I have a form with multiple submit buttons, each of which is relevant to how the user wants the data saved and/or loaded.
The problem is (or was) that if a user pressed enter on the last (or any other) input within the form, the submit button that seemed to be called was the "load saved formed" which is at the top of the form. All attempts to user javascript to have the return button default to the "save form" seemed useless, almost as if the browser was too busy already submitting the form to have any js interfere.
Finally, in FireFox 3.5, I actually had the server-side script echo out what it received for the post variable and discovered that none of the submit button values were being passed back to the server. As it turns out, I have hooks in the script for when the user hits "Save" or "Save and Print", etc, but if the user uses the "load page" it simply updates a variable and continues loading the page normally with that variable in context.
So with no submit button value at all, it did the same thing, it simply loaded the page.
So, on to the big question:
Is this typical browser behavior? Maybe even reliable browser behavior? Will hitting enter always submit the form as though no submit button was pressed at all, or do some browsers like to pick a button to use as the default when the user presses enter?
If it is typical behavior, what is the suggested course of action? I was going to have the script save anything no matter what, so long as there was data in the form, but then I realized that this was even more dangerous, because if the user loads one saved form, changes there mind, and changes the form dates and hits "Load Form", then it will save the form data from the pervious form for the new dates they have requested.
I considered setting it up so that changing the load form inputs (selects with dates and other particulars) would clear the form so that the server still recieved an empty form and thus would not overwrite any previous data, but this is risky as well, as many users will certainly notice and think that their data has been lost, etc, and there is always the slight chance that the user will be almost done with the form, go up to the top and fiddle with the form-load selects just to confirm they chose the right what nots and then be forced to start from scratch.
I should just have two forms, one for loading, one for the data, but the problem with that is that all of the data in the load part of the form does get used by the main form. I could write more js to combine the two on submit, or hide the data in the second form, but all of that seems clunky.
Essentially, I need a setup such that the top part of the form is independent of the main form, but not vice versa. Submitting the upper form does not submit the lower, but submitting the lower does submit the higher.
Okay,I've gone on long enough. Basically I'm wondering if a solution already exists or if anyone else has run into this and found a clever fix. I thought simply having the form save whenever the form wasn't empty was pretty clever, until it occurred to me that when the user goes to the page, it auto-loads the most applicable form given the date, and thus changing the load variables will almost always caused trouble.
Having read the possible duplicate that Artelius was good enough to draw my attention to, I'm still unclear on the consistency across browsers regarding the Enter button as submit.
It seems that almost everyone in that question assumed that hitting enter presses the first available submit, which was also my assumption until a friend suggested I hide (via CSS) another submit button at the top of the form with whatever I wanted enter to achieve. It was when this got me the same results that I finally viewed what was being passed to the server (ie nothing in terms of a submit value). So that means either
a) the "enter as no submit button just submit" is new behavior for some or all browsers,
b) the "enter as just submit" vs "enter as first submit button" is just browser choice, no trends, just typical cross-browser unreliability, or
c) Everyone just keeps assuming that the "enter as first submit button" is the case because most of us only code if (situation1) else (assume not situation1) and none of us are really sure what the browser is doing.
I highly doubt it's that last one, but then again, I also highly doubt most of us know which browsers do which. I'd sure like it if there was a straight answer I could pass along.
Oh, and finally: While I know it would be far simpler to use buttons, and I am taking that under serious consideration, I would also like to consider other options, since really the only need for less submit buttons I have is for when users hit enter instead of one of the buttons.
Actually, let me get carried away one more second:
The only thing I really need to know is whether or not they hit enter FROM one of the text inputs. If I could pass that along to the server, I'd know if I should save or reload the form. But the problem is (or at least what I've had troubles with) is that when the user hits enter in an input, it seems like there isn't any more playtime with js to capture anything, and in some cases, it seems like the browser is triggering the onclick for whichever submit button and thus not really allowing me to know the real event that triggered that. I'll play around more with jquery, but has this behavior been observeed by anyone else?
My best advise would be to only have on submit button, and let that submit what ever is the most common usage of the form. Let the rest of the buttons just be normal buttons, which you can hook click events onto.
Just make sure you make it very clear which button will be "pressed" when the user hits enter. Let the submit button be the biggest one. If you have 3 buttons that are used equally as much, I would just drop having a submit button at all...
edit: I'm pretty sure most browsers will post all the data inside a form. If you want to do some checking on the data before posting you could add a listener for onsubmit
<form onsubmit="checkData(this);" ... >
Passing in this will let you check which form is actually being submitted:
function checkData(form) {
var formName = form.id;
//check all the data based on which form is being submitted
}
The HTML5 spec specifies synthetic click activation steps for implicit form submission:
A form element’s default button is the first Submit Button in tree order whose form owner is that form element.
If the user agent supports letting the user submit a form implicitly (for example, on some platforms hitting the "enter" key while a text field is focused implicitly submits the form), then doing so for a form whose default button has a defined activation behavior must cause the user agent to run synthetic click activation steps on that default button.