In Firefox, at least, native HTML5 input element validity, e.g. a required text field, shows up as a red border, but only after interaction.
e.g. in the example below, I initially see two input boxes. If I type something in one of them, delete it and press Tab, the first one now glows red to show me it's invalid (because it's required).
Using Javascript, how can I reset the form to the pristine initial state, where the red border is not showing?
<form action='#'>
<div>
<input required name="a" type="text" />
<input required name="b" />
</div>
</form>
The only reliable way I've found is to reset the form, either via a <button type="reset"> or through form.reset().
Note, however, that this will wipe the values of any and all fields in the form, so if you need these to remain you'll need to repopulate their values after the reset is done.
Setting <form novalidate> will work, however subsequently removing the novalidate attribute will make the field(s) show errors again.
Related
there.
I have the simplest form with the code:
<script>
var field1 = document.querySelector("#field1")
var field2 = document.querySelector("#field2")
field1.addEventListener('focus', function (e) {
field2.removeAttribute("disabled")
})
</script>
<form action="/" method="POST">
<input id="field1" name="field1" required="" type="text" value="">
<input disabled="disabled" id="field2" name="field2" type="text" required="" value="">
<input id="submit" name="submit" type="submit" value="Save">
</form>
After entering data, sending the form and stepping back, I see no data in the second field. Why?
Before sending data:
After sending data and stepping back in a browser history with a mouse back button:
When sending data by clicking on the Save button, the values in both the input are being sent. But, when you step back you are effectively reloading the page. On reloading, two things are happening:
The page DOM is reset to its initial state i.e. to the markup in your HTML. Since, in your initial HTML markup, field2 is set as disabled, on page reset the same thing happens.
The browser is autocompleting the previous values that were filled in the inputs. This is a feature of the browser itself and if it were not there, then even in the first field there would've been no data on stepping back. You could verify this by adding autocomplete="off" to the first input field.
Therefore, as your browser implements autocomplete on page reload (due to stepping back), the first input field is filled but the second input field is not because it is reset to its disabled state.
I have a little challenge when testing a website. Just wanted to see if you folks have any suggestions on this. The story behind this is that I need to mask the input fields for the screenshots when the test has been executed as we are sharing the data with other teams. Before the script I am running JS with 'document***.type="password";', but when script starts to type, then input type is changed back to the type of text. Also, class changes from class="is-invalid" to class="is-focused is-invalid" when it's active. Also, I could of course change the type after I have typed the value, but even tho when I click the next field, the class changes. When I have filled the first input field it checks the data against the server and the class is of course changed.
I have an input field when inactive:
<input ref="input" value="input field" id="id-for-unified-text-input--14fe" name="unified-text-input-14fe" type="text" autocomplete="off" spellcheck="false" placeholder="ABC123" class="is-invalid">
And the input field when active"
<input ref="input" value="input field" id="id-for-unified-text-input--14fe" name="unified-text-input-14fe" type="text" autocomplete="off" spellcheck="false" placeholder="ABC123" class="is-focused is-invalid">
Any suggestions from a fellow testers, how could I fix this? Thanks a lot in advance!
As pretty much evident from the HTML the <input> field whenever recieves the focus_ the classname is-focused added.
This addition of classname is pretty much controled through the attributes, presumably the css_properties of the parent elements.
As as conclusion, it would be difficult to mask the password field characters from the clientside and have to be controled from the Application Server side.
I am disabling the inputs using the isFetching prop,
but this is getting reduntant as I have to keep this in every input field.
Is there a way to disable the entire form?
Like a disable property in <form> tag or something?
<form>
<input type="text" disabled={this.props.isFetching} />
<input type="text" disabled={this.props.isFetching} />
</form>
I think this should solve your problem https://stackoverflow.com/a/17186342/3298693.
You should insert your form inside an element <fieldset disabled="disabled">. This will make the whole form disabled.
I had the same issue and this worked for me:
<fieldset disabled={true}>
Where true would be some "prop.setting"...
Just use <input type="text" disabled> wherever you want the input text to be disabled. It hardly takes some time.
HTML has 13 form elements and the input element has 23 different types. My question is what is the reasoning behind making a form element a type of input or its own element?
At first I thought maybe its because all input types are just variants on input type=text, but that doesn't make sense when you throw checkbox and radio into the mix. Perhaps they would be better as their own form elements?
<input type="checkbox" name="check" value="yes">
// Would become
<checkbox name="check" value="yes">
Another form element that doesn't make sense to me is textarea for two reasons.
According to How to change the Content of a with Javascript you can use element.value to both set and retrieve a textarea's contents. Yet textarea doesn't have the value attribute, at least its not shown in the DOM.
The way textareas behave when resetting a form is inconsistent with other form elements. All input elements will be reset to the value of their value attribute. But a textarea is reset to whatever its 'value' (quotes because it doesn't have a value attribute in the DOM) was set as when the page loaded.
Example 1 (consistent with input): If you click the reset button, both input and 'textarea' will be reset to their 'initial' values (Example use jQuery). JSFiddle
<form>
<input type="text" name="text" value="initial" />
<textarea>initial</textarea>
<button type="reset">Reset</button>
</form>
<script>
$('input, textarea').val('set by javascript');
</script>
Example 2 (inconsistent with input): You cannot use .attr('value') with textarea elements, which means the following example doesn't work. You have to use $('textarea').text() or $('textarea').html() in order to set the default value.
<form>
<input type="text" name="text" value="initial" />
<textarea>initial</textarea>
<button type="reset">Reset</button>
</form>
<script>
$('input, textarea').attr('value', 'set by javascript');
</script>
There are other things that don't make sense to me but I will only highlight these two in my question. I'm hoping someone can explain to me why HTML and Javascript treat form elements differently (specifically when its comes to getting, setting, and resetting their values), and why certain form elements have their own elements and why others are just types of the input element.
I have am trying to reset a textbox using the $setPristine function in AngularJS, however it doesn't seem to result in the desired behavior.
My form looks like this:
<form name="addInviteForm" ng-controller="InviteCtrl" ng-submit="sendInvitation(userEmail)">
Pristine? {{addInviteForm.$pristine}}
<!-- email input -->
<div>
<input type="email" name="email" ng-model="userEmail" placeholder="Enter email here" class="line-item-input see" required>
<span class="error" ng-show="addInviteForm.email.$error.email" style="color:red">Invalid Email</span>
</div>
<!-- submit button -->
<input type="submit" name="send" class="btn btn-success center" value="Send Invitation">
</form>
And the corresponding code in my controller:
$scope.sendInvitation = function(userEmail) {
// do some work here ...
// hmm, this doesn't seem to work ...
$scope.addInviteForm.$setPristine();
};
Though the form shows that $pristine is set to true upon form entry, then set to false when entering data in the text-box, after submitting the form it does indeed show that $pristine is set to true .... and yet the value in the textbox remains as it was before the submit button was pressed.
What am I missing here?
$setPristine does not clear values from the controls in the form:
From the docs:
Sets the form to its pristine state.
This method can be called to remove the 'ng-dirty' class and set the
form to its pristine state (ng-pristine class). This method will also
propagate to all the controls contained in this form.
Setting a form back to a pristine state is often useful when we want
to 'reuse' a form after saving or resetting it.
As you can see from the above description, $setPristine only changes the state of the form (and thereby resets the css applied to each control in the form).
If you want to clear the values of each control, then you need to do for each in code.
This plunker shows $setPristine in action.