HTML form doesn't contain a form submit button name when using the Enter key - html

My ASP.NET MVC 3 website has code on the server side that checks for the name of the submit button clicked to submit the form. The code works when I use the mouse to click the button, but when I use the Enter key, the form gets posted, but the request doesn't contain the name of the submit button.
Is there some attribute I can set on the submit button to get this to work for both clicking and using the Enter key?
Here is my HTML:
<div>Search:</div>
<form action="/Item/Search" method="post">
<input class="fulltextsearch" id="FTSearchText" name="FTSearchText" type="text" value="" />
<input type="submit" value="Go" name="FTSearchButton" />
</form>
</div>
On the server side, I have a custom model binder that uses the following code to determine if the user clicked the submit button.
// See if the value provider has the required prefix
var hasPrefix = bindingContext.ValueProvider.ContainsPrefix(bindingContext.ModelName);
var searchPrefix = (hasPrefix) ? bindingContext.ModelName + "." : string.Empty;
var searchButton = GetValue(bindingContext, searchPrefix, "FTSearchButton");
// If this value doesn't have value, the user didn't click the button so exit
if (string.IsNullOrEmpty(searchButton)) {
return null;
}
private static string GetValue(ModelBindingContext context, string prefix, string key) {
var result = context.ValueProvider.GetValue(prefix + key);
return result == null ? null : result.AttemptedValue;
}
Here is the problem I'm having with this. I have a page that displays a list of items. I have a 'search' textbox and a submit button in an HTML form. When the user enters text in the textbox and clicks the search button or uses the enter key, the page posts the form data via HTML GET, and returns the first eight records found. The page then displays page links for additional pages. The problems is that when the user clicks a page link, the form data is all blank, and my filter information is lost (the form isn't posted with the form value when using these links). So, I end up displaying a blank list of items (blank searches returns zero results) instead of paging the data.
By adding the check for the button name in my form data, I could determine whether or not to simply page the data, or do a new look up.

I wouldn't rely on this. There are plenty of documented bugs with this scenario. Just add a hidden field with name='submit'. That way it wouldn't be too hard to recode the backend.
<input type='hidden' name='submit' value='FTSearchButton'/>

So, I researched this last night and almost got somewhere. Then this morning, I really did get somewhere and here's where I ended up.
Apparently the W3C standards for form submission are pretty lax when describing the functionality as it relates to the Enter button and submitting forms. It seems they determined that
When there is only one single-line text input field in a form, the user agent should accept Enter in that field as a request to submit the form.
So that leaves a lot of wiggle room for the browser makers. Today, virtually all browsers support using the Enter key to submit a form, whether the form contains one or more single line text input boxes.
The problem I'm having is more or less unique to Internet Explorer, and only when the form contains one, single-line text input control. For whatever reason, Microsoft decided that when Internet Explorer submits a form like this, it doesn't include the submit button's name/value pair in the post body. However, it does include the button's name/value pair if the user clicks the submit button --or-- uses the Enter key, and the form contains more than one single-line text input control.
So, the only solution I can think of or find suggested is to add a second single-line text input to my form, and then set the the style to
visibility: hidden; display: none;
My form now has two single-line text input controls, so the form will post with the name/value pair in the form body, regardless of whether or not the user used the Enter key or clicked the submit button.
So, we have a workaround that was discovered by ASP.NET developers. It seems the key/value pair is required by ASP.NET web-forms to fire the click event, so this work around isn't something new, albeit not my favorite way to do things.

Related

WWW::Mechanize: How To Click Button Based On Its Number in Form

There is a button on a website at the end of a form that I cannot seem to click with WWW::Mechanize. Here is the bit of HTML pertaining to this button:
<input type="submit" class="saveButton" value="Login">
When I print $mech->find_all_inputs();, I get return this:
HTML::Form::TextInput=HASH(0x7f8f52cdc450)
HTML::Form::TextInput=HASH(0x7f8f5302b488)
HTML::Form::SubmitInput=HASH(0x7f8f52cdc108)
The third one is the one I want to click. I'm not exactly sure how to click this button even though I've found it. I tried click(field(n => 3)), I tried assigning a variable $submit to find_all_inputs(3), then click($submit);, and no matter what, this button is not clicked.
Can anyone guide me as to how to click this elusive button?
Edit (after question answered)
Interrogating the HTML form found I was actually entering the password for the login into the 'Forgot my Password' field of the form. Why this field was not coming up for $mech->find_all_inputs(), I don't know since "Login" was. Either way, clicking the button takes me to the next page. Thanks!
Since it is the first button in the form, you can write this
$mech->click_button( n => 1 )
or, since it's value attribute is Login, you can do this
$mech->click_button( value => 'Login' )
But since it is the only button in the form, just
$mech->click
should work fine
Did you try to select the appropriate form first, then call click? It says (my emphasis)
Has the effect of clicking a button on the current form.
Find which form on the page you need. Let's say it's form number 2.
# $ua is the User Agent (Mechanize object), at the appropriate page
$ua->form_number(2);
# fill the form ...
my $response = $ua->click();
or
$ua->submit_form(
form_number => 2,
# fields => { name => $value } # can fill it here as well
};
I find click to be perhaps more reliable overall.
To inspect the forms you can use my #forms = $ua->forms. To fill the form you can use select or set_fields, for example. See Form Methods and Field Methods. All this operates with HTML::Form objects so you can use its methods as well. For example, value_names and possible_values are handy.
If this doesn't help please give us more detail -- the web page in question would be ideal.

Are HTML buttons with no values submitted in a form?

if you have
<button class="button yellow" type="submit"
name="button">Log in</button>
and you submit it, what gets posted to the server for the button which has a name but no value attribute?
The reason I ask is that I'm parsing HTML forms, and need to post the named values that send data to the server. I got the others covered, but wasn't sure about button.
According to the HTML Spec, a button's value is either determined by its value attribute or is an empty string. A button's value is only submitted with the form if the button has a name and is used to initiate form submission. If the button in your example is clicked, the resultant submission will be:
"button=" (quotes added)
Some browsers (mainly older IE versions) have incorrect implementations of this button behaviour that either set the value to the button's contents or submit all button values regardless of initiation source.
button does not get posted to server when the form is posted. Only input type's like text, password, select elements etc., which accepts user inputs will be posted to the server
Button never supplies value to form. It just provides a submit event that tells the browser to submit that form with all the input tags to the action attribute inside your form tag using the method attribute value. Button only provides the event and not the values.
There will be nothing posted to the server for buttons. When you click a button, it invokes the action of submit, that is all.
I tried it out by printing the request.POST in django.
This image shows a "Log in" button with no value but name="button", as asked
The console shows
< QueryDict: {u'csrfmiddlewaretoken': [u'9aAx..'], u'sensor': [u'sd1'], u'button':[u'']}>
So, in this case, the form is sent as a dictionary and for the buttons the key, value pair is "button" : " ". So, if you try to get value of this button with request.POST.get, you will get NULL.
So, the answer to your question is the form consolidates all the input values, which can be accessed with their 'name' including buttons. If no value is provided, it returns NULL.

Why Firefox autocomplete even with different input name?

Or How does Firefox determine where the password/username goes?
If I change name, id, title, class of an input element Firefox keeps filling it with password or email.
If I understand Firefox's source code correctly, the browser first looks for password fields in forms. If form contains more than 3 password fields, the autofill function ignores that form.
After 1 to 3 password fields are found, the browser looks for login field. The browser does a backward search starting from first password field and assumes that the login field is the first found field of the type text or email or url or tel or number.
Next step depends if we check the forms on page load or when submitting the form.
If we check during page load and there is a login field and exactly ONE password field, the case is simple and the browser can fill out the form.
Other cases (form submit or more than 1 password field) do some “smart” logic to determine which password field contains new password and which one the old password, probably to update stored passwords). If you're interested in details, download the source code and open toolkit/components/passwordmgr/nsLoginManager.js file. Functions to check are _fillForm, _getFormFields and _getPasswordFields.
Just to summarize, Firefox doesn't need any ID, name or class attributes to guess which field is login or password. It just relies on types and the order of form fields.
I tried a simple solution that is working so far. Create 2 hidden fields and the browser will autofill those.
<input type="text" style="display: none">
<input type="password" style="display: none">
Looks like using a disabled input text between login and password inputs does the trick well :
<input type="text" disabled="disabled" style="display:none">
Are those the only two elements on the form? Firefox is likely storing the structure of the form (two input boxes, one flagged as normal, one flagged as password) and filling in saved information without respect to the ID of the input elements.
Try this: add an extra input element to the form and see what happens. Either Firefox will not fill in anything, or you'll find your name in the first field and the password field filled in, while the second input element is blank.

Mystery .x and .y form fields - where do these come from?

Take a look at this login page, specifically, the form in the section labeled Returning Members. As you can verify by looking at the HTML or by digging with a tool such as Firebug, the actual form contains four tags: one each for the email address and password, an invisible input called "memberAlready" that contains the value "yes", and a submit button in the form an image. So far, perfectly generic.
However, if you inspect the form data at the point at which the form is submitted (using Tamper Data or its equivalent on another browser, you'll see that two additional form fields have been sneaked into the response: ACTION(loginCheckout).x and ACTION(loginCheckout).y.
They both have two-digit integer values, which suggests that they're only there to verify that the submitter is an actual web browser and not a robot. Presumably, they are related somehow to the submit button, which is defined as follows:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
What's confusing to me is that these extra form fields appear even when JavaScript is disabled in the browser. So they presumably aren't just something inserted by an event handler somewhere.
Furthermore, if you submit the form programmatically (e.g., by running document.forms[1].submit() in the JavaScript console), the extra fields are not generated and the login attempt fails. That suggests to me that the insertion of the fields depends on something outside the basic HTML form submission mechanism. But what that "thing" could be if it's not JavaScript, I don't know.
Does anyone recognize this pattern or have a theory as to how the validation fields are inserted?
Take a look at the code you posted here:
<input type="image" name="ACTION(loginCheckout)" value="Login" src="/images/login/login.gif">
Notice that this is an image input type which is used to submit the login form. The additional values that appear to be injected on submission are simply the x and y coordinates where the you clicked on the image to submit the form. They are not additional values which are injected by JavaScript on form submission, they are added by the browser itself.
Try clicking on different areas of the images and see the values change.
When you use JavaScript to submit the form, you do not click on the image, which is why the x and y values are not included on form submission.
Replacing the image for an <input type="submit" /> element will remove the x and y coordinates.
Hope that helps.
The X and Y values you are seeing are because the submit button is an an input type=image. They correspond to the X and Y locations within the image where the cursor was when the image was clicked. They're added by the browser itself, as the HTML specification requires it. Section 17.4.1 states that for an image input type
When a pointing device is used to click on the image, the form is submitted and the click coordinates passed to the server. The x value is measured in pixels from the left of the image, and the y value in pixels from the top of the image. The submitted data includes name.x=x-value and name.y=y-value where "name" is the value of the name attribute, and x-value and y-value are the x and y coordinate values, respectively.
You'll note it only mentions the use of a pointing device. If you submit by using the keyboard the values won't be created.

Set Focus to a textbox after data validation in .ASP page

I am working on an asp page that verifies information in a text box after the user types it in.
A “product number” is manually entered (free form). Using the after update event, I have the page post the data and lookup the product number to determine if it is valid. If not valid an error message is posted in the box, otherwise the product number and description is placed in the box (I.E X1234 becomes X1234 – RED YO-YO). This works 100% fine. My problem is that after the update the focus is lost on all the data entry items. I want the focus to be returned to the next text box so the operator can type in the next piece of needed information.
Note: So far I inserted a function that dynamically changes the “TABSTOP” numbering such that the “next” box is assigned the #1 after the validation lookup. This works on my browser (Firefox 3.05) but is does not on my IE (Thanks Bill ! ). In IE when the posting is finished the focus for some reason ends up on the “enter the URL” and hitting tab puts the focus on some control button that is no where near where I want it to be.
If you are trying to do what I think you are, this should do it.
In your ASPX page:
<script type="text/javascript">
function focusControl(ctrlId) {
document.getElementById(ctrlId).focus();
}
</script>
In your code-behind:
// 'ctrl' is the name of the ASP.NET TextBox that you want to receive
// focus on load.
Page.ClientScript.RegisterStartupScript(
typeof(Page),
"Focuser",
"focusControl('" + ctrl.ClientID + "');",
true);
Here is the general solution:
http://couldbedone.blogspot.com/2007/08/restoring-lost-focus-in-update-panel.html