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.
Related
I am working on a form that makes use of the HTML5 form validation attribute required for various text and radio button fields. The form also has two sets of checkboxes, of which at least one checkbox must be checked.
In order to keep the user error feedback consistent I am using the setCustomValidity method to throw a native error bubble when the checkboxes are left unchecked. This all works fine, however, there is an issue with error feedback when the form is submitted and the onsubmit event is used to trap unchecked checkboxes. This issue doesn't arise when the onclick event is bound to the submit button instead, but I understand it is preferable to use onsubmit.
Onclick test case (Click submit button and error bubble appears first time!)
http://jsfiddle.net/Jimadine/bZe5e/
Onsubmit test case (Click submit button - error bubble appears after second click)
http://jsfiddle.net/Jimadine/2vLszqac/
Furthermore, from my testing of the onsubmit case, Firefox highlights the unchecked checkboxes after the first click of the submit button; this is indicated by a red glow around the checkboxes. Then after a second click the error bubble displays. In other modern browsers the first click displays no on-screen indication that the checkboxes were left unchecked; I presume this is how the UX side of HTML5 validation was implemented in these browsers and that Firefox chose to do things slightly differently.
My question is why does the onsubmit test case require two clicks and what is an appropriate way to rectify this so it behaves like the onclick test case? I'm guessing it has something to do with the submit event firing after the validation but I'm not sure how to correct my code.
Here is a working jsfiddle base on your first example http://jsfiddle.net/bZe5e/6/.
The key is instead of doing this only on submit/button click. You are checking the validity on change + initially
doValidate();
I came across a similar problem, and for me it worked calling
reportValidity() right after setCustomValidity().
function onSubmit(e){
e.preventDefault();
const myInput = document.getElementById('my-input');
if( inputIsInvalid ){
myInput.setCustomValidity('My custom invalidity message.');
myInput.reportValidity();
}
}
Reference: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Constraint_validation#constraint_validation_process
Given the following code:
<html>
<head>
<script>
function updateTabIndex() {
setTimeout(function() {
var elem = document.getElementById("id1")
elem.setAttribute("tabIndex", 2)
elem.setAttribute("value", "now: tabindex 2")
}, 100)
}
</script>
</head>
<body>
<h1>Weird Behaviour When Changing the tabindex in onchange Handler in Internet
Explorer</h1>
<p><input id="id1" tabindex="-1" value="tabindex: (-1)"/></p>
<p><select tabindex="1" size="1" onchange="updateTabIndex()" onpropertychange="updateTabIndex()">
<option>tabindex 1 - an option</option>
<option>tabindex 1 - another option</option>
</select></p>
<p><input tabIndex="3" value="tabindex 3"/></p>
<h2>Instructions</h2>
<ol>
<li>Open this page in IE. To be precise, the problem is reproducible in
(at least):
<ul>
<li>IE 8, Version 8.0.6001.18702CO on Windows XP and</li>
<li>IE 9, Version 9.0.8112.16421 on Windows 7 Professional, 64 bit</li>
</ul>
<li>Use the <em>mouse</em> to change the value of the select box.</li>
<li>As you can see, the onchange handler is called and changes the tabindex
of the first input element.</li>
<li>If you now tab out of the select box, you can see that the tab order is
adhered to correctly: you go from the select box to the first input element
and then to the last element on the page.</li>
<li>Close the page and open it again.</li>
<li>Click on the third input element and press Shift + Tab to enter the select
box.</li>
<li>Use the down arrow key on the keyboard to change the selected value in the
select box.</li>
<li>Now tab out of the select box.</li>
<li>As you can see, the onchange handler is called, as before (the text in
the first input field has changed).</li>
<li>However, if you tab around now, you will see that the tabindex attribute
is ignored. Instead the order of the elements in the document source is used
as the tab order.</li>
<li>Even if you change the select box value with the mouse now, the tab
order remains broken. To test again, you need to close the page and open
it again or reload it by entering the url bar and pressing enter. Hitting
F5 will not be enough.</li>
</ol>
</body>
</html>
IE ignores the changed tab order when the select box value (which triggers the change to the tabindex attribute) is changed by some keyboard action (arrow keys) but does not ignore the tabindex change when the select box value is changed with the mouse (see more detailed explanation
about the expected and perceived behaviour in html above).
Why does IE behaves like that? In particular, why is the behaviour different when using the mouse and when using the keys. Is it a bug in IE? Right now, I'm pretty sure it is a bug in IE here, but of course there is also the chance that I'm doing something wrong which just happens to work as expected in FF.
I already googled quite a bit, but as far as I can see, this bug (if it is one) has not been reported or discussed anywhere until now.
Some remarks
First of all, Firefox does not exhibit this weird behaviour.
Just to avoid being misunderstood, it is clear that, when I tab out from the
select box, I'll get to the to the input with tabindex 3, because the
asynchronous code in the onchange handler might not have been executed yet.
But after that (when the text in the first input has changed), I expect the
new tab order to be established. This is how FF behaves.
It seems that IE already fires the onchange event each time I use the up/down
arrow key and not when I leave the select box (as FF does). I'm not sure if
that is related to the problem.
Added Bonus: If you open the IE developer tools you will see that the tabIndex
attribute is set correctly in the DOM, also when changing the select box value
without the mouse. But the tabindex is ignored when tabbing around.
My (naive) guess is that IE keeps an internal representation of the taborder
and that this internal representation is not recalculated correctly in this
case.
More weirdness: You can delete lines 5 and 9 of this file (setTimeout call and
closing curly brace), so that the tabindex change is no longer called
asynchronously. It then works correctly if you enter the select with the mouse
and leave it by tabbing out. It still breaks if you tab into the select change
the value with the arrow key and tab out.
In the JSFiddle, changing your code to set the JavaScript property instead of the attribute seems to help...
elem.tabIndex = 2;
// elem.setAttribute("tabIndex", 2);
A colleague of mine found an interesting workaround: Just add
elem.parentNode.replaceChild(elem, elem)
after setting the tabindex makes it work. Seems this DOM manipulation triggers a recalculation of IE's internal tab order which is missing otherwise.
While this is better than no solution, it's quite an ugly hack. :-(
If anybody knows a different, less brute force solution, I'd be still interested.
I encountered a similar issue when dealing with hidden radio buttons in IE 9. I set the tabIndex to -1, but you could still tab to the radio group. My workaround was to alter the CSS visibility property, which forced IE to ignore the group.
To conceal radio buttons from IE 9's strange tabbing behavior:
$radioBtns.attr('tabIndex', -1).css('visibility', 'hidden');
To reveal radio buttons and resume standard tabbing behavior:
$radioBtns.removeAttr('tabIndex').css('visibility', '');
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>
I am learning JavaScript through the Head First series book by O'Reilly media, and I just reached a chapter where I have to use the onchange event.
I'm testing using Safari/OS X Lion, Firefox, Chrome, Opera, and IE/Windows, but got the same result.
Given this code:
<html>
<head>
<title>onChange Test</title>
<script type="text/javascript">
function itWorks(){
alert("it works!");
}
</script>
</head>
<body>
<form>
<input type="text" onchange="itWorks();" />
<input type="text" onchange="itWorks();" />
</form>
</body>
<html>
Is it correct to say that the onchange event works whenever we change from one field to another, whether it is activated only by clicking or by using the TAB key?
The onchange event fires when:
Focus leaves the field
if the value has changed since focus was gained
It doesn't matter how focus was lost, and focus doesn't need to move to another field (a link could be focused, or nothing in the document could be, etc).
"we change from one field to another, whether its by clicking or by
using the TAB key" -
Thats onblur.
the event you have coded fires whenever you change the value of the input, then leave the field. EG: Enter something into the field, then press the TAB key.
Your example code works as expected for me.
The behaviors you described is onfocus. onchange executes when the value of the input changes.
If you type something into the field, it should run.
"Just to clarify, the onchange event works whenever we change from one field to another, whether its by clicking or by using the TAB key, right?"
Yes - as long as the value has changed
I'm not sure what the question is tbh - your code works!
I tested it on jsfiddle.net - which is great for learing / testing javascript.
(you should close your html tag btw)...
This is what the HTML5 draft spec says:
The unfocusing steps are as follows:
If the element is an input element, and the change event applies
to the element, and the element does not have a defined activation
behavior, and the user has changed the element's value or its list of
selected files while the control was focused without committing that
change, then fire a simple event that bubbles named change at the
element.
Unfocus the element.
Fire a simple event named blur at the element.
Note that change can fire at other times too. The spec also says:
... any time the user commits a change to the element's value or list of
selected files, the user agent must queue a task to fire a simple
event that bubbles named change at the input element.
And goes on to provide a couple of examples of "committing a change"
An example of a user interface with a commit action would be a File
Upload control that consists of a single button that brings up a file
selection dialog: when the dialog is closed, if that the file
selection changed as a result, then the user has committed a new file
selection.
Another example of a user interface with a commit action would be a
Date control that allows both text-based user input and user selection
from a drop-down calendar: while text input might not have an explicit
commit step, selecting a date from the drop down calendar and then
dismissing the drop down would be a commit action.
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.