For reasons I won't go into we need to click a submit button (as opposed to a plain button) via Javascript.
We do this by getting a handle to the submit button, then executing the .click() method on this button. This works perfectly in FireFox, but in IE6 it only works partially.
The button receives the click, and code associated with the buttons "onClick" event fires (we can observe this by watching the server-side code in the debugger) however, the page never "refreshes" the way it should when clicking a "submit" button.
Since this works in FireFox, we assume it is yet another IE6 bug, but I'm not having any luck finding a work-around. We can't simply refresh the page directly because we need it drawn as though it were drawn from the submit button POST request.
Wouldn't it be easier to get a reference to the form element and fire the submit event?
var form = document.forms[0];
form.submit();
I have the same issue in ASP.net. We must "click" the button because there is more that happens in ASP.net with a form than just the normal .submit() on the form. It has to know which button you clicked so it can match it up to the Click event on the server-side for that button.
Try using setTimeout to delay the click by 1 millisecond.
Related
I have a simple form inside a Bootstrap modal popup. The form was working fine until I needed to add a button to perform a simple calculation based on some values entered into the form.
The button just has a jQuery click event which grabs the values from the form elements, does the calculation the writes that value into a text box. When the form is not in the modal, it works just fine. Zero errors. When the form is in the modal clicking the button closes the modal and I cannot see why.
I have stripped back the button to bare bones and even removed the jquery code in the click event handler.. it still closes the modal. I have removed the form action event (points to a .php script), but the modal still closes.
When it closes I see that the browser address bar is filled with the URL for the page with all the form values as params as the field were populated when I clicked the button.
Can anyone tell me how I can get this button to just be a trivial button I can use for this purpose and NOT close the modal?
I have removed the form action event (points to a .php script), but the modal still closes.
Removing the action attribute just sets the action to the URL of the current page. It doesn't prevent the form from being submitted.
Can anyone tell me how I can get this button to just be a trivial button I can use for this purpose and NOT close the modal?
The crappy quick way
<button type="button"> will make the button a JavaScript only button and not a submit button
The proper way
In your event handler function, capture the event object and call its preventDefault() method.
Make sure that on those occasions when the JS fails, the server does the right thing and provides a sensible response for the form submission.
The probelm is very likely that the button submits the form. Try specifying <button type="button"> or add a evt.preventDefault() in the click handler.
For a Drupal site I've developed a rather simple module to prevent users of pressing multiple times on a submit button. When the submit button is pressed it's replaced with a small message to have some patience.
The problem in all browsers it seems to work fine with the exception of Safari.
$("input[id^='edit-submit']").click(function(e){
var message = Drupal.t('Please wait...');
$(this).hide();
$('<span>' + message + '</span>').insertAfter(this);
});
When I look into the debugger I see an attribute appearing style="display: none;" but Safari seems to ignore it. When I manually (through the developer tools) add a display:none the button disappears.
I don't know it jQuery doesn't run in Safari on form submit is related because when I add a console.log() between the click function body it is executed once (the $(this) value also points to the correct element) but it doesn't respond to any changes on that button.
It seems that from the moment you click on the submit button it is in some kind of locked state - which would also prevent double submits - but I want to be rather sure this is standard behaviour for safari then a bug that could haunt me in the future.
I've tried googling on certain keywords but I couldn't find anything documentation that describes this behaviour in Safari.
EDIT: I also tried removing (and detaching) the button on the onclick which makes the button disappear, but then the form doesn't get submitted anymore.
Try to use:
.css('display', 'none');
I have the following code in an MVC view that I'm using to test window.history.back()
If the user clicks the link (highlighted in red) within the paragraph tag, window.history.back() executes as I would expect. It takes me back to the prior page with state maintained on that page. However, if the user clicks the button, I don't get the same behavior. The current view is reloaded, or at least an attempt is made to reload the current page. But it fails. And it doesn't matter if the jQuery is executed, or I put the window.history.back() call within the Button onClick, the same thing happens.
A piece of information which might be helpful. The button is inside an HTML.BeginForm and the line in the paragraph tag is not.
Anyone know why this is happening?
The browser is probably interpreting the button as a submit button and submitting the form, thus causing a page refresh. Adding type="button" will prevent that.
<button type="button">Cancel</button>
$('#cancelButton').click(function(e){
e.preventDefault();
/* ... code ... */
});
Based on someone's advice I added this line $('body').on('touchstart', function(event){ event.preventDefault() }) in my mobile webapp to disable the native app bouncing in iOS. It works great for disabling the bounce but gives me some weird behavior elsewhere in DOM.
Click events that don't work, etc. I was hoping to get a better understanding of what this does and how to work around it's effects elsewhere in the DOM.
Thanks!
EDIT:
I have these two lines:
$('body').on('touchstart', function(e){ e.preventDefault() };
$('#home').on('click', function(){ alert('home') };
If I comment out the preventDefault line then the #home line works. If I leave it in the #home line doesn't respond. #home is just a div nested in the body.
Any idea what could be causing this behavior? It's part of a bigger codebase so it;s hard to give you all the details but I don't even know where to start.
Thanks Again!
e.preventDefault() tells the browser that if there is a default behavior for this event on this object, then skip that default behavior.
So, for example, if you had a submit button that the default behavior was to submit a form and you had a click handler on that button that did a preventDefault(), then the browser would not submit the form when the button was clicked. A classic use of this might be when the form doesn't validate so you show the user an error message and don't want the form to be submitted to the server.
Or another example. If you set up a click handler for a link and you call e.preventDefault() in that click handler, then the browser will not process the click on the link and will not follow the href in the link.
To prevent users from submitting a form twice, I disable the submit button after a click with:
$('a').on('click', function(){
$(this).button('option', 'disabled', true);
});
On Chrome, the default action (following the link / executing the JS in the href attribute) is executed. On IE9 however, nothing happens and the button stays disabled. I tried poking around it in the respective JS debuggers and it seems both events are processed in the same phase.
You can see it in action on jsFiddle: http://jsfiddle.net/inerdial/yXWBn/2/
Is there any reason for this behaviour, and/or a workaround less hackish than manually triggering the button's default action somehow?
In case it's any relevant, the submit button is an ASP.NET LinkButton, styled with jQuery UI.
You can try putting that logic into a setTimeout call
You have to set UseSubmitBehavior="false" on the submit button and everything will work as expected.