I have an input text box on which there are handlers for events like focusOut, input
Now, I expect the "input" event to be trigerred/handled first and then the "focusOut" (as I use the entered value in focusOut)
The above sequence works consistently on Chrome, FF. However, in IE11, the sequence is a bit unpredictable i.e. in certain cases, the focusOut triggers first and then the input
From what I observed, this is mostly when I enter the value in that field and directly click on the Submit btn on my form using my mouse.
Is that a known IE11 issue ?
Looks like you are saying that onfocusout is executing first then oninput event.
I try to test this sample code with IE browser and it looks fine.
<!doctype html>
<html>
<head>
</head>
<body>
<input type="text" id="input" onfocusout="alert(this.value)"> oninput: <span id="result"></span><br>
<input type="submit" value="submit">
<script>
input.oninput = function() {
result.innerHTML = input.value;
};
</script>
</body>
</html>
Output:
Let me know if I am missing anything. I will try to correct myself.
This query of adding extra fields by add button is working on Google chrome, but not in Internet explorer. Please help me to work it out in IE 11.
<html>
<head>
<script>
function add_field()
{
var form = document.getElementsByTagName('form')[0],
input = document.createElement('input');
input.setAttribute('type', 'text');
input.setAttribute('name', 'item');
form.appendChild(input);
};
</script>
<form name="input" method="get">
<div class="ui-input-text">
<input type="text" name="item"><br>
<div data-role="navbar">
<button type="button" onclick="add_field
()">ADD</button><br>
</div>
</div>
</form>
</body>
</html>
In my experience, internet explorers (of various versions) have issues assigning the "name" attribute to elements. I found the following custom method works for anything:
Element.prototype.customAttribute=function(customname, customvalue){
var z=document.createAttribute(customname);
z.value=customvalue;
this.setAttributeNode(z);
}
The script is working fine, although you need to allow it to run scripts on the site. Internet Explorer will block the script until the user confirm that he/she wants it to run.
internet explorer prevented this webpage from running scripts or activex controls
I used Internet Explorer 11 on Windows 7 64-bit. No errors occurred and everything functioned.
The following simple form with javascript with onclick button does not work in Firefox (I have version 7) but works fine in IE, Chrome, and Safari.
What am I missing?
<head>
<script type="text/javascript">
function result() {
alert(calc.input.value);
}
</script>
</head>
<body>
<form name="calc" action="">
<input class="cInput" type="text" name="input" size="16" /><br/>
<input type="button" class="cButton" name="seven" value="1" onclick="calc.input.value += '1'" />
<input type="button" class="cButton" name="equal" value="=" onclick="result()" /><br/>
</form>
</body>
<script type="text/javascript">
var calc;
function result() {
calc = document.forms['calc'];
alert(calc.input.value);
}
</script>
What am I missing?
You are missing that IE adds element names and ids as global variables. Some other browsers in certain conditions (sometimes requiring the document to be in quirks mode) will copy that habbit, some wont.
So in IE (and some others) the form name calc is a global variable referencing the form and in other browsers it isn't.
The method in Dunuyadnd's answer is a robust, cross-browser way to get a reference to the form. The formal access method is:
document.forms['calc'];
Named form controls can accessed similarly:
document.forms['calc'].elements['input'];
or
document.calc.input;
Be careful with giving controls names that are the same as tags, it is a bit confusing. Also, if there is more than one control with the same name, you will get an HTML collection rather than a single element.
You may want to read about HTMLForms and their related elements.
I've got a strange bug, well, MSIE does.
Seems it is failing on all major MSIE versions: 6, 7, 8 and 9 (!)
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-gb" lang="en-gb" ><head><title>test</title>
<script type="text/javascript" src="http://code.jquery.com/jquery-1.4.2.min.js"></script>
<script type="text/javascript">
jQuery(document).ready(function(){
var test=jQuery('#in');
test.focus(function(){
if(test.val()=='empty')test.val('');
test.attr('readonly',false);
});
test.blur(function(){
if(test.val()=='')test.val('empty');
test.attr('readonly',true);
});
});
</script>
</head><body>
<input type="text" value="empty" readonly="readonly" id="in"/>
</body></html>
Let me explain how this system works and what is going wrong.
When the user clicks (focuses) the input box, the input box should be made editable (ie, lose readonly flag). Then, when s/he leaves the input box (ie, blur event) some processing is done (not shown in code) and the input box is made readonly.
This works like a charm in most browsers (firefox, opera, webkit-based), but not any version of IE (including 9 beta).
The problem is that in IE, the user has to click the input box twice.
At this point, you might ask is the inputbox left readonly the first time?
No. I tested it, javascript reports that it is editable.
Easy fix, just fire a click event on the input box (to simulate the user's double click behavior), no?
No, .click() and .focus() both failed. No idea why.
Edit: Know that the cursor does show up in the text box, at least visibly.
Important: People, please do at least try the code before answering!
I wouldn't say it's a bug.
If you change the value, you also remove the current textRange.
Try test.select() , it should give the cursor back to the input.
test.focus()
will result in a loop that will end in an "not enough memory"-error.
I believe that readonly should be readOnly. Seems weird you would toggle this property. You can also try to remove it
jQuery("#foo").removeAttr("readOnly"); //.removeAttr("readonly");
try this ive just tried that and it works:
<input type="text" value="empty" id="in" readonly/>
Why is it that a <form> with a single <input> field will reload the form when the user enters a value and presses the Enter, and it does not if there are 2 or more fields in the <form>?.
I wrote a simple page to test this oddity.
If you enter a value in the second form and press Enter, you'll see it reloads the page passing the entered value as if you called GET. why? and how do I avoid it?
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>testFormEnter</title>
</head>
<body>
<form>
<input type="text" name="partid2" id="partid2" />
<input type="text" name="partdesc" id="partdesc" />
</form>
<p>2 field form works fine</p>
<form>
<input type="text" name="partid" id="partid" />
</form>
<p>One field form reloads page when you press the Enter key why</p>
</body>
</html>
This is a little known "Quirk" that has been out for a while. I know some people have resolved it in various ways.
The easiest bypass in my opinion is to simply have a second input that isn't displayed to the user. Granted not all that user friendly on the backend, it does work to resolve the issue.
I should note that the most common place that I hear of this issue is with IE specifically and not with FireFox or others. Although it does seem to affect them as well.
This is a known bug in IE6/7/8. It doesn't appear that you will get a fix for it.
The best workaround you can do for this, is to add another hidden field (if your engineering conscience permits). IE will no longer auto-submit a form when it finds that there are two input-type fields in the form.
Update
In case you were wondering why this is the case, this gem comes straight out of the HTML 2.0 specification (Section 8.2):
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.
No, the default behaviour is that on enter, last input in the form is submitted.
If you don't want to submit at all you could add:
<form onsubmit="return false;">
Or in your input
<input ... onkeypress="return event.keyCode != 13;">
Of course there are more beautiful solutions but these are simpler without any library or framework.
Pressing Enter works differently depending on (a) how many fields there are and (b) how many submit buttons there are. It may do nothing, it may submit the form with no 'successful' submit button, or it may pretend the first submit button was clicked (even generating an onclick for it!) and submit with that button's value.
For example, if you add an input type="submit" to your two-field form, you'll notice it too submits.
This is an ancient browser quirk going back at least as far as early Netscape (maybe further), which is unlikely to be changed now.
<form>
Invalid without an ‘action’. If you don't intend to submit anywhere, and you don't need radio button name grouping, you could just completely omit the form element.
Here is the code that I used would use to solve the problem:
<form>
<input type="text" name="partid" id="partid" />
<input type="text" name="StackOverflow1370021" value="Fix IE bug" style="{display:none}" />
</form>
It's not reloading the page as such, it's submitting the form.
However, in this example because you have no action attribute on the form it submits to itself which gives the impression of reloading the page.
Also, I can't repro the behaviour you describe. If I am in any text input in a form and I press Enter it submits the form, no matter where in the form the input is located or how many inputs there are.
You might want to try this out some more in different browsers.
as vineet already said, this is rooted in the html 2.0 specification:
here is how to prevent this from happening without screwing up your urls:
<form>
<input type="text" name="partid" id="partid" />
<input type="text" style="display: none;" />
</form>
Thanks to everyone who answered. It's an eye opener that a form with a single field acts differently then a form with many fields.
Another way to deal with this automatic submit, is to code a submit function that returns false.
In my case I had a button with an onclick event, so I moved the function call with the added return keyword to the onsubmit event. If the function called returns false the submit won't happen.
<form onsubmit="return ajaxMagic()">
<input type="text" name="partid" id="partid" />
<input type="submit" value="Find Part" />
</form
function ajaxMagic() {
...
return (false);
}
The solution I found for all of the browsers that I tested (IE, FF, Chrome, Safari, Opera) is that the first input type=submit element on the form has to be visible and has to be the first element in the form. I was able to use CSS placement to move the submit button to the bottom of the page and it did not affect the results!
<form id="form" action="/">
<input type="submit" value="ensures-the-enter-key-submits-the-form"
style="width:1px;height:1px;position:fixed;bottom:1px;"/>
<div id="header" class="header"></div>
<div id="feedbackMessages" class="feedbackPanel"></div>
...... lots of other input tags, etc...
</form>
This problem occurs in both IE and Chrome.
It does not occur on Firefox.
A simple solution would be to add the following attribute to the form tag:
onsubmit="return false"
That is, of course, assuming that you submit the form using an XMLHttpRequest object.
Yes, form with a single inputText field working as different in HTML 4.
onSubmit return false not working for me but the below fix bug is working fine
<!--Fix IE6/7/8 and HTML 4 bug -->
<input style="display:none;" type="text" name="StackOverflow1370021" value="Fix IE bug" />
I handled this by the following code but I am not sure if this a good approach.
By looking for input fields in a given form and if its 1 prevent the default action.
if($j("form#your-form input[type='text']").length == 1) {
$j(this).bind("keypress", function(event) {
if(event.which == 13) {
event.preventDefault();
}
});
}
I think that's a feature, which I did also disable it though. It's not taking big effort to disable it. Just capture the enter key, ignore it, will do.