Mixing ajax and full requests - javascript

I have an ajax and full request in the same form. A mouse click fires the ajax in the input field and if I press enter on the same input field right after the mouse click then a nasty error pops up which is shown below.
"The Http Transport returned a 0 status code. This is usually the result of mixing ajax and full requests. This is usually undesired, for both performance and data integrity reasons."
In my case the input field is a radio button which uses ajax. Pressing enter is causing a full request.
I used BalusC's Javascript function which has event.stopPropagation() which worked for me and it was for a text input field. It also worked for a drop down list.
But the same event.stopPropagation() is not working for a radio button.
You can check BalusC's answer for reference.
Below is my piece of code which doesn't seem to work
<h:form id=blah...... onkeypress="enterToChange(event)">
....
</h:form>
The Javascript function
function enterToChange(event){
if (event.keyCode==13 && event.target.id.match('radiobutton_id'){
event.stopPropagation(); // Don't bubble up.
event.preventDefault(); // Prevent default behaviour (submitting the form).
event.target.onchange(); // Trigger onchange where key was actually pressed.
}
}
I used firebug to see that the statements in the if clause are executed but the error still pops up for some reason and immediately the whole page is rendered. I need to avoid the error in any case.
Any answer is highly appreciated.
Thanks

Enter is bound to submit. So if the event keyCode is 13 and event target id matches that of the radio button, then the onclick event for the submit button should fire a JS function which returns false.

Related

event trigger on submit

I want to perform javascript validation after user submits the form. Documentation for jQuery .submit() clearly says:
The submit event is sent to an element when the user is attempting to submit a form.
But if I put
$('form.simple_form.new-channel').submit perform_validation()
into my code, perform_validation() is triggered every time page is rendered! Even when there is no form on it and no 'submit' button. What is the correct way to call a function after submitting a form?
I believe You dont want to trigger action after submitting, You just want to run it after user clicks submit button.
Wouldn`t it work put like that?
$('form.simple_form.new-channel').submit(function(e){
if(!perform_validation()){
e.preventDefault(); //prevents form from being submitted if validation fails
return; //exits function
}
})
Your perform_validation function should then return Boolean value.
EDIT:
You wrote Your function like this:
$('form.simple_form.new-channel').submit perform_validation()
which is exact the same as writing:
$('form.simple_form.new-channel').submit;
perform_validation();
In Your version script just runs the perform_validation() because it isn`t inside event handler.
You could also do it this way:
$('form.simple_form.new-channel').submit(perform_validation);
This one tells the script to run on the form submit, the function which name is passed as an argument.
The problem is your syntax.
$('form.simple_form.new-channel').submit perform_validation()
Because of javascript's liberality the fact that you are not invoking submit here and you have no semicolin after perform_validation... causes no error, but simply invokes perform validation as if it was on the line all by its self with a semicolin.
to correct this, do this
$('form.simple_form.new-channel').submit(perform_validation);

What triggers an HTML form to submit?

I apologise in advance for not being able to provide any actual code, as the problem appears in a page which is currently private :-/ Please bear with me.
I have an HTML form. I attached a (proprietary) calendar widget to one of the text input fields. When the user tabs into the field the calendar appears. On the calendar there are a couple of buttons (to move to the previous/next month). When the user clicks on one of these buttons the calendar updates itself accordingly, but also - the form submits! There's NOTHING in the calendar code that touches anything other than the calendar itself and the text input field it is attached to, let alone submits a form! I would appreciate any clue regarding any of the following questions:
1) What could possibly have submitted the form in such a setting?
2) What things generally submit a form, other than clicking on the submit button or hitting the enter key? (In particular, do ordinary buttons submit forms? Under which circumstances?)
3) As a workaround in case I don't manage to figure this out, is there a way to simply totally disable submitting the form (and then reenable it in an event handler attached to the submit key)?
Note(s): The calendar behaves normally other than that - responds normally to key events and to click events on the dates themselves (which are not buttons). I tried this on both Firefox and Chrome and got the same behaviour. I tried to follow the click event handler step-by-step with FireBug, and everything seemed perfectly normal - but the moment it finished the form was submitted (and the page reloaded). The widget uses jQuery 1.7.2. Any help in understanding and/or solving this will be most appreciated!
Sorry to answer my own question, but none of the given answers was complete, even though I've learnt from them and from the comments! Thanks for everyone who participated!
So:
1+2) Buttons defined by the <button> element cause submits (as if they had type="submit" set. At least in some browsers). If one wants a button not to cause a submit one should use <button type="button">, or the good old <input type="button" />.
3) (Unnecessary for me now, but it was part of the question.) There are many ways to prevent a form from submitting. Three of them are:
to handle the onsubmit event, preventing the submit (by return false; or - preferably! - by e.preventDefault();) in case a flag is not set; set the flag when handling the event(s) that should actually submit the form
to handle the onsubmit event and prevent the submit as above if the element that triggered the event is not (one of) the element(s) we want to cause a submit
to set the form action to non-action, i.e. action="#", and to have the handler for the event that should actually submit the form set the action to the proper address
The calendar can submit your form in its JavaScript source code by calling form's submit() method using jQuery or plain JavaScript.
Here is an example how to disable the form submit and allow it only in case of pressing the button.
<form id="form">
<input type="text" />
<input type="button" name="submit-button" value="Submit"/>
</form>​
<script type="text/javascript">
var form = document.getElementById('form'),
button = form['submit-button'];
form.onsubmit = function(e) {
return !!form.getAttribute('data-allow-submit');
};
button.onclick = function() {
form.setAttribute('data-allow-submit', 1);
form.submit();
};
</script>
Demo
The calendar code isn't calling submit() somewhere?
3) As a workaround in case I don't manage to figure this out, is there a way to simply totally disable submitting the form (and then reenable it in an event handler attached to the submit key)?
Unfortunately, I'm not totally sure if it's reliable that the click handler will be called before the form submit event.
( function () {
var prevent_submit = true;
$( "form" ).on( 'submit', function ( event ) {
if ( prevent_submit ) {
event.preventDefault();
}
} );
$( "input[type='submit']" ).on( 'click', function ( event ) {
prevent_submit = false;
} );
} )();
or
$( "form" ).attr( { action : "#", method : "post" } );
$( "input[type='submit']" ).on( 'click', function ( event ) {
event.target.form.action = "...";
} );
Hitting enter on text fields can sometimes trigger a form submit. See here. Especially if that is the only element in the form. One way to control the post back is to set the action to empty and fire off the event yourself with Javascript.
Check the placement of the closing form tags. I had this problem once and I finally figured out that there was some 'permissions' code within the form itself that prevented the user from reaching the closing tag because he didn't have the proper permission level to submit it. In effect this left an open form tag that then responded to other buttons elsewhere on the same page.

JQUERY click handler from DIFFERENT element triggered on enter?

URL is here: http://prorankstudios.com/sandbox/wtf/
Using IE9, with focus on the User or Pass field, hit the ENTER key...
Notice that this whole page reloads.
What's happening is that the click handler for the #live_site_link (assigned on line 30 of common.js) is running when no click has happened on #live_site_link at all...
Login Submit code:
Login.Submit = function(e)
{
Login.feedback.empty();
if (Login.user.val() == '')
{
Camo.ErrorAlert('Invalid username.',Login.feedback);
Login.user.focus().select();
return false;
}
if (Login.pass.val() == '')
{
Camo.ErrorAlert('Invalid password.',Login.feedback);
Login.pass.focus().select();
return false;
}
Camo.AJAXStart('Logging in...');
postData =
{
user:Login.user.val(),
pass:Login.pass.val()
}
Camo.AJAXPost('index/login/',Login.Success,Login.Failure,postData);
return false;
}
live_site_link click handler:
$('#live_site_link').click(function()
{
window.location.href = './';
});
In fact, the handlers for the login form (both a keyup and a click on Go button assigned in login.js lines 22 and 24 respectively) sometimes run AFTER the page has reloaded, strangely enough.
In IE7/compatibility mode, the keyup and click handlers for login_submit properly work and the page does not reload. This is also the case in all other browsers I tested.
What is IE9 doing?
Try calling e.preventDefault() or e.stopPropagation() before you return false in Login.SubmitOnEnter
It would be better though if you wrapped a form around your form elements, then attached an event for the form submit. That way it will still work without javascript and you wouldn't have to have a separate event for click and enter press.
The only "fix" for this I could figure out short of changing the live site link button to a regular anchor tag was actually to enclose the login fields and button inside form tags.
Apparently without those enclosing form tags, IE9 is using the live_site_link button instead of the GO button to submit the form on a natural enter key press before the keyup handlers on the inputs and the click handler on the Go button of the login form ever get a chance to trigger, which causes the page to reload (as that's what the click handler for live_site_link does).
Now I have to handle logins without AJAX...
You would probably manage the login submittal process easier by using a submit handler rather than needing to catch enter key and make it click on submit button. Seems like extra code to work around doing it a simpler way
$('form').submit(function(){
var valid=someValidionFunction();
return valid;
})
Edited due to no ajax

I have problems with keydown event and autocomplete in Firefox on mac

This is driving me nuts. Its a tough one to explain but I'll have a go.
I have one input text field on the front page of my site. I have coded a keydown event observer which checks the keyCode and if its ENTER (or equiv), itll check the input value (email). If the email is valid and unique in the DB itll submit the form. Basic stuff, or so you would think.
If I type my email address in the field and hit enter, it works fine in all browsers. However, if I type the first couple of letters, and then use the arrow keys to select the email from the history dropdown box (hope you know what I mean here), and then press enter the result is different. The value of the form field is being captured as just the couple of letters I typed, and therefore the validation is failing. It seems that when I press the enter key to "select" the email from the history dropdown, the browser is interrupting that as if I was typing.
In Chrome and Safari it works as it should. As it should means that when you press enter to "select" the email from the history dropdown, all it does is puts that email address into the text box. Only on the second ENTER key press does it then trigger the event observer, and the email is validated.
Hope somebody can shed some light on why this is happening... My gut feeling is its a browser thing and will be something I cant fix.
Thanks
Lee
EDIT:
To add clarification to my question let me add that Im using the "keydown" event to capture the moment when the enter key is pressed. I have tried the "keyup" event and this solved my problem above, but then I cant seem to stop the form submitting by itself. The "keyup" event triggers AFTER the default behaviour, therefore its not the right choice for this.
FURTHER EDIT:
Thank you again, and btw, your English is excellent (in response to your comment about bad English).
I have changed my event handler from this:
$("emailInputBox").observe("keydown", function(event) {
return submitViaEnter(event, submitSignupFormOne);
});
to this:
$("emailInputBox").observe("keydown", function(event) {
setTimeout(submitViaEnter.curry(event, submitSignupFormOne),0);
});
submitViaEnter:
function submitViaEnter(event, callback) {
var code = event.keyCode;
if (code == Event.KEY_RETURN) {
event.stop();
return callback(event);
}
return true;
}
Seems to work but the problem now is that the browser is permitted to carry out the default action before running the submitViaEnter function which means the form is being submitted when I hit ENTER.
Answer to the original question
Yeah, it's a Gecko bug (not Mac-specific though).
The last part of this comment contains the description of the work-around: use the time-out.
[edit] since you asked for the clarification of the bug
When you press Enter and the auto-complete is active, Firefox (erroneously) first fires the page's key handler, then the browser's internal key handler that closes the autocomplete popup and updates the text area value, while it arguably should just fire it at the autocomplete popup and only let the page know the textbox value changed.
This means that when your key handler is called, the autocomplete's handler hasn't run yet -- the autocomplete popup is still open and the textbox value is like it was just before the auto-completion happened.
When you add a setTimeout call to your key handler you're saying to the browser "hey, run this function right after you finished doing stuff already in your P1 to-do list". So the autocomplete's handler runs, since it's already in the to-do list, then the code you put on a time-out runs -- when the autocomplete popup is already closed and the textbox's value updated.
[edit] answering the question in "Further edit"
Right. You need to cancel the default action in the event handler, not in the timeout, if you want it to work:
function onKeyPress(ev) {
if (... enter pressed ...) {
setTimeout(function() {
... check the new textbox value after letting autocomplete work ...
}, 0);
// but cancel the default behavior (submitting the form) directly in the event listener
ev.preventDefault();
return false;
}
}
If you still wanted to submit the form on Enter, it would be a more interesting exercise, but it doesn't seem you do.
ok sorted it. Thanks so much for your help. It was the curry function that I was missing before. I was trying to work on the event inside the scope of the setTimeout function.
This works below. The submitViaEnter is called from the eventobserver and responds to the keyDown event:
function submitViaEnter(event, callback) {
var code = event.keyCode;
if (code == Event.KEY_RETURN) {
event.stop();
setTimeout(callback.curry(event),0);
// return callback(event);
// return false;
}
return true;
}
Stopping the default action inside the eventObserver meant that no characters could be typed. So I stuck inside the if ENTER key clause.

javascript commands not all firing

I have a very simple JavaScript function:
function insertPost()
{
document.postsong.submit()
parent.document.getElementById('postSongButton').disabled = true;
}
Both commands in it work but only the first one will fire. This is true when they switch places also. Only the first one will fire...
document.postsong.submit()
Submits the form, takes focus away from the function, function ends there
parent.document.getElementById('postSongButton').disabled = true;
Disables the button, so perhaps it is that there is then nothing to submit the form.
Not too sure if disabling the form button would stop the event from bubbling, but I suspect that the nature of these two lines will lead you to separating them, and having the second one in another event handler.
Hope this points you in the right direction.
EDIT: On further inspection, I found that the real source of the problem is the line:
document.postsong.submit()
Here are the results of my tests in different browsers. If the line previous to the submit() is "button.disable = true", and the button type="submit":
Firefox disables the button and submits the form.
Chrome disables the button, but does not submit.
IE does not disable the button, but it does submit the form.
This explains the behavior you have been experiencing. Having parent before getElementById does not hurt anything, but it is not necessary. Change the code in your insertPost() function to this:
function insertPost(){
document.getElementById("postSongButton").disabled = true;
document.forms["postSong"].submit();
}
Did you check the casing of the html element?
on click of the button you are calling the funcion insertPost().so what you have to do first disabled the button and then submit the form.one think i didnt understand why are using parent of object.
function insertPost()
{
parent.document.getElementById('postSongButton').disabled = true;
document.postsong.submit();
}
You are using parent.document.getElementById(...
Just check if you are referring to the button correctly. i.e. if the parent reference you are using is correct. i.e if the button is in same page as the form or in the parent.
And yes, first you have to disable the button and then trigger the submit action for the form. When you do it the other way, you might end up navigating away to a different page and the disabling line may never execute.
But, since you said, disabling doesn't work for you at all, I thought if you were using wrong reference. Did it give any javascript errors for you when you tried to disable it?

Categories

Resources