I created a form to be processed with javascript only (no submit) and found that Google Chrome was erasing all the inputs when I popped up an alert. After some experimenting, I found that Chrome behaves differently depending on whether the javascript alert is called from button element or an input element. In particular, the HTML button causes the text in the input box to be deleted when you click OK. This does not happen in IE. I have not tried it in other browsers. It does not happen with the input element, and it does not happen with the button element if it is outside the form.
Has anyone else noticed this, or know of a reason why it should be so?
<form>
<p>Enter some text in the input box, then click one of the buttons.</p>
<input type="text"><br>
<input type="button" onclick="alert('What happens to form values?')" value="Input button"> <br>
<button onclick="alert('What happens to form values?')">HTML button</button>
</form>
The <button> is submitting the form when clicked.
Submitting the form reloads the page.
To prevent this, add return false to the end of the handler.
based on w3schools http://www.w3schools.com/tags/att_button_type.asp
Always specify the type attribute for the element. Different browsers may use different default types for the element.
in your case you want the type to be button (otherwise some browsers will default to submit)
<button type="button" onclick="alert('What happens to form values?')">HTML button</button>
Related
I am writing HTML dialog forms, with data-entry fields, where a "Cancel" button can be clicked to exit the modal dialog. Which one of the "submit", "reset", and "button" <input> types is most appropriate for a cancel button and why?
Research
The MDN page on <dialog> elements provides an example where <button> (without type attributes) is used for both cancel and confirm buttons: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog#Advanced_example
The MDN page on the HTMLDialogElement.showModal() function provides a similar example where <button type="reset"> is used for the cancel button: https://developer.mozilla.org/en-US/docs/Web/API/HTMLDialogElement/showModal
I've also read around online, including some answers on this site, where <input type="button"> was used in recommendation examples.
To summarize my understanding:
Omitted type or type="button" buttons do not imply that the button will submit a valid form nor' that the form will explicitly reset your data entries. However they require you to write more JavaScript to close the dialog unlike type="submit". The markup also doesn't indicate that this is one of the ways of closing the dialog form.
Buttons with type="reset" imply that the data entries will be cleared and event.preventDefault() is required to contradict the markup. However, resetting is not ideal (https://ux.stackexchange.com/a/42773), you still need to write JavaScript to close the dialog, and the button's function contradicts the markup due to the form being closed with JavaScript or if you decide to prevent the data reset.
Buttons with type="submit" may imply being alternative means of closing/completing the dialog and the dialog is automatically closed when submit-type buttons are clicked. You only need JavaScript to listen for close events and to check the <dialog>'s returnValue attribute to see if cancelling happened. However, the markup / submit-type may imply that the form will be submitted with valid entries instead of cancelling.
Considering this, if my understanding is valid (?), and any other reasons that I might be oblivious to (concerning what markup is most readable and presents the most elegant use of JavaScript), which approach should be taken for Cancel buttons in dialog forms?
Sample:
<dialog id="forCloseEventListener">
<form method="dialog">
<input type="text" name="data-entry" placeholder="Enter your post code">
<input type="??" value="Cancel">
<input type="submit" value="OK">
</form>
</dialog>
P.S.: I've noticed there's an experimental HTMLDialogElement 'cancel' event, but it's subject to change and its MDN page seems inaccurate or incomplete.
Type type="button" is the best choice. You can write a function and use in the onclick event to exit the modal as you want.
If you use submit or reset you will need to prevent their default behavior, using event.preventDefault().
I am newbie in Angular and struggling with a problem here. I have an input type text which is read only (through ng-readonly). I have a separate button on click of which I have to call a javascript function openPopup which opens a pop up and then I choose something on popup and on clicking ok on popup, we come back to main page and the readOnly text input is updated with some value.
My problem is I want to capture this text change event of input Text, read that text value and then do some action in Angular.
Although the text field value is getting changed, the corresponding ng-model data.currentLot is not getting updated. I tried putting ng-change, using $apply $watch, onchange event, but nothing seems working. Am I missing something very simple here.
<div class="form-group">
<input type="text" ng-readonly="'true'" ng-model="data.currentLot" class="form-control" id="chooseLotId" placeholder="">
<button type="submit" class="btn btn-default" onclick="openPopup('chooseLotId', false);">Search Lots</button>
Thanks to suggestion from instantNoodles, I was able to solve the problem. As soon as a selection was made from pop up, the pop up was getting closed and focus came to my input text. I captured the onfocus event and that solved my problem.
I just test same code on IE10 and Chrome Browser.
jsfilddle link
<div id='a'><input onclick="console.log('a');"/></div>
<div id='b'><button onclick="alert('b');"/></div>`
I put two different tags which are input and button in two different div tags.
both elements(input, button) have onclick attribute.
what I do is simple
put a cursor in input tag
press enter key
I tried this on IE10 and Chrome.
In chrome browser the event handler attached on button has not executed.
but in IE event handler attached on button has executed.
can anyone tell me why this disaster happens
IE is handling like a brain damaged boy the "enter" key press. Pressing Enter in textbox/input/etc in IE will click the completely unrelated button near it. Is the only browser with this approach.
It's related with the IE's algorithm for selecting submit buttons. Your button is considered one, even when no form tag is present.
<button onclick="alert('b');"/> has default type = "submit"
You can change that by changing the type with the button one.
<button type="button" onclick="alert('b');"/>
Working fiddle : http://jsfiddle.net/k1bkcx43/
This behaviour is related to implicit form submission which is correctly implemented by Chrome as per HTML5 spec. You can go through the spec here.
In short 'hitting the enter key' while a text field is focussed invokes browser controlled implicit form submission which in turn looks for first submit button under the 'form' element and invoke the attached handler.
In your case the 'button' element is defaulted to 'submit' type but since it is not a decendent of 'form' element hence it will not be invoked.
You can assume that current IE behaviour is not as per spec.
I have a strange problem where an onclick event on an input image is being fired when i hit enter in input text box
<form id="MyForm" action="/someaction">
<input type="image" src="someimage.jpg" onclick="doStuff();$('#MyForm').submit();" />
<input type="text" name="textInput"/>
</form>
When the cursor is in the text box and i hit enter, rather than the form being submitted it calls the onclick event on the image input.
Any ideas whats going on ?
I believe pressing the 'enter' button counts as a click in many cases, including links. If you want your action to be performed only when the mouse is used, then consider using onmousedown or onmouseup instead of onclick, I'd suggest the latter in your case.
So I had a similar problem and it was only happening in IE. Chrome and firefox were working just fine. When hitting enter from the input box, it would trigger the first input type="image" which we did not want because it would send multiple requests to IE and after hitting enter a few times it would crash.
The quick and easy work around, though not the best solution, we used was to put a dummy input type="image" with an onclick return value of false before the other ones so that the one being triggered wouldn't actually fire off a request. Not the correct root solution but a good temporary one.
The onclick event is fired on input images when you hit enter. I'd wrapping an <img> in an <a>, as since you're separately calling submit(), the input element is made redundant.
I'm having trouble with events in Internet Explorer 7.
When I have a form with two or more input[type=text] and I press enter, the events occurs in this order:
submit button (onClick)
form (onSubmit)
Sample code:
<form onSubmit="{alert('form::onSubmit'); return false;}">
<input type="text">
<input type="text">
<input type="submit" onClick="{alert('button::onClick');}">
</form>
If I have only one input[type=text] and I press enter the submit button onClick event doesn't fire. Sample code:
<form onSubmit="{alert('form::onSubmit'); return false;}">
<input type="text">
<input type="submit" onClick="{alert('button::onClick');}">
</form>
The button's onclick should (I think) only fire if the button is actually clicked (or when the focus is on it and the user clicks enter), unless you've added logic to change that.
Is the addition of the extra textbox possibly changing the tab order of your elements (perhaps making the button the default control in that case)?
From the dawn of browsers, a single input field in a form would submit on enter with or without a submit button. This was to make it simpler for people to search a site from a single search field.
If you need to execute some javascript in a form, it is safer practice to use the onsubmit of the form (and return false to stop submission) rather than executing script in the onClick of the submit button. If you need to execute javascript from a button, use type="button" instead of type="submit" - hope this clarified what I meant
If you want code to run when the user presses enter, just use the onSubmit handler.
If you want code to run when the user presses the button, and not when the user presses enter, use a button other than type="submit".
Interestingly, if you click on the screen (remove the focus from the textbox) on second example with only one textbox, the event onClick fires... So it's not an expected behaviour since it only occurs when you have just one textbox and you have the focus on the textbox.
I'm afraid you've found a bug on the browser and you'll have to find a workaround, or avoid using the onClick event in that case.
I use the onSubmit event for validations because it's a "safer" event that is more likely to work on different browsers and situations.
Out of curiosity, are you using a DOCTYPE, and if so, which one? I'm not saying incompatabilities with the DOCTYPE are the issue, but quirks mode is something to rule out before trying anything else.
You might want to include a dummy hidden input element to recreate the situation where you had two input elements... that way, you'll get both of the events fired
<FORM onSubmit="{alert('form::onSubmit'); return false;}">
<INPUT TYPE="text">
<input type="hidden" name="dummy">
<INPUT TYPE="submit" onClick="{alert('buttom::onClick');}">
</FORM>
IE has a lot of confusing fixes that needs to be done for improving compatibility of our code