When a input textbox is disabled, you can not enter any values into the Inputbox.
However if you use google chrome and right click on the inputbox then click on inspect, you can change the values.
How do you stop people from editing a disabled inputbox?
You can't. The only thing you can (and always should) do is validate user's input on server.
There is no way you can stop people from changing its state and sending the data. There are two way you can do this
Do not display the disabled input at all. Just like what Zend_Form does.
Check the field when the form was submitted and remove it.
As I known, the disabled input value won't be posted to server side. So if someone change the value using tools, the modified data will not be posted.
Related
In my form, the user can toggle the visibility of certain form elements using Knockout in order to save space. If the elements are visible and the user has not filled out the required fields, when they press the save button, HTML5 will notify the user of the required fields. However, when the elements are hidden, the save silently fails in that pressing the button does nothing.
The only indication to the user that something is wrong is that the save button does not respond. Of course in the console it has the familiar message 'An invalid form control is not focusable'.
Have you dealt this with issue before? How did you address it? I don't want to take away the required attribute. I suppose that one solution could be to validate with JavaScript for those types of fields instead of HTML5. Suggestions are appreciated.
Similar question:
An invalid form control with name='' is not focusable
use form submit instead of read value from selector. because HTML5 required filed will work if form get submitted.
I'm working on a form that have several fields with user's information (like his address) and, in the same form, several checkboxes and radio buttons. I want to keep autofill on, but only for the text fields. The radios and checkboxes all have custom events that trigger some ajaxes to update the page summaries and some other things.
Problem is: I did put autocomplete="off" on all fields I don't want autofill to mess up.. and that does work. But on chrome, when you have an autofilled a form, a "clear form" option shows up when you double click any field that is part of the autofilled form.
This clear form triggers a reset on the form object but this reset just don't fire any event. And it clears the whole form, even the radios and checkboxes. This breaks the functionality of my form because the custom events on the radios and checkboxes are not triggered.
The only solution I could think was to, using javascript, try to cache the current selections on the fields and keep comparing using a interval function... but that looks like a lame solution to me... it is kind of heavy and not very intuitive for other people to maintain this code. Does anyone know if this is a chrome bug or if there is any secret event I should be listening to, instead of "reset"?
Thank you
I have a form with a read only field for display/submit to the next page purposes.
However, I noticed using developer tools in Chrome, I was able to add an id to an element, use the javascript console to select that element, and change its value. I submitted the form and what do you know - the next page acted on it as if it was the original value.
Now, there shouldn't be any problem with the people using the site I'm building, but it seems like a huge security flaw to me. Isn't the point of read-only to remain constant? If a savvy user to change it around, doesn't that pose a big problem? In fact, I didn't even think you could add and change attributes in chrome.
Please post your thoughts below, and let me know if there's a solution ("disabled" textfield, but setting the disabled property doesn't send the data to the next page).
NEVER trust input from a web form.
The user could, just as easily, remove the readonly attribute and edit the value. The readonly attribute is only something to help the user when filling out the form, so they don't edit a value expecting it to change, when your server actually won't let it be changed. So, always remember to code the behavior on your server first, and have the HTML form be a helpful guide for users to make the form easier to fill out (without having to submit the form several times to get relevant error messages).
To overcome this, if something is readonly and you do not want it edited, you could store the value in your database. Also, values provided by users should always be checked (and sanitized) as no amount of JavaScript, HTML, or CSS is going to prevent someone who knows what they're doing from adding new or changing/removing existing values.
The 'estimatedvalue' attribute of the opportunity entity is marked as being required. I have it on the form, but have marked it as being disabled, both through the Form UI customization, as well as using javascript, but some other javascript is re-enabling the form after I've disabled it.
The best solution I have so far is disabling the attribute from the callback of a timeout: setTimeout("CommonLib.setDisabled('estimatedvalue', true);", 1);. When the field loads, it loads as disabled, then some other js is enabling the field, then the callback from the timeout runs and disables it again, so you see the field go from grayed out, to black, to grayed out.
There are two other attributes that I've disabled and they stay disabled, but the estimatedvalue is the only one that is actually required, so I'm guessing it has something to do with that.
Any ideas as to what is re-enabling the field?
I dont think it has anything to do with the requirement level but #Anwar may be one explanation. Could you double check if some other custom script might be enabling the field?
I just tried following with the task where subject is the required field and it seems to be working fine:
Xrm.Page.ui.controls.get('subject').setDisabled(true);
I'm debugging a weird problem with two simlar search forms - when user types some search criteria in a text box and hits enter, one form returns results and another just reloads. And it happens only in IE - FF treats both forms as expected. I suspect that hitting enter is triggering onclick for one of the search buttons in one case and something else in another.
How do I find what form element caused submit event?
Thanks,
Andrey
Sounds like the single textbox form bug in IE.
To get around it, you can use Javascript to handle the enter key press, or just insert a blank hidden textbox. Lame, I know.
I suspect that hitting enter is triggering onclick for one of the search buttons in one case and something else in another.
Yes. Browsers may, largely at their whim, treat enter as clicking on a submit-button, just submitting a form, or nothing. Put general form submission stuff in form.onsubmit, rather than an onclick on the first submit button.
You could sprinkle your form elements with onclick events to set a hidden form variable with a different value per element, then sniff the results either with a DOM inspector or through something like Fiddler.
There may be a way to simply have a form onsubmit() event that you can extract the triggering element from the event object, but I'd have to dive into the docs to see if this is possible... if I get chance I'll do some looking.
I think I may help you much If you provide your two forms code. However, check to see for the following submit button code:
<input type="submit" value="Submit">
When you use this, then when you press Enter among the corresponding form, the form will be submitted. If you wish to check something before submitting you can use JavaScript Function like the following:
<input type="button" onclick="javascript_function_name();" value="Submit">
Thanks. If this can not help you, please express the situation more briefly.