Jquery: how to handle "stop/cancel" event when user stops form submit?

Question

I found this question but it wasn't answered: Is there a jQuery event that I can monitor if form submission is cancelled?

So if the user submits a form, while it's loading the user pressed "esc", or clicked "stop" button of the browser, I want to invoke a function, is it possible?

Note: I know we can bind "esc" button, but what about if the user stopped the submission by the browser's "stop/cancel" button?

Is there a JavaScript or jquery possible solution?

EDIT:

I know we can handle this issue with XHR (json/ajax) post, but I'm looking for a normal form submission.

Simply what I'm trying to achieve is this: when the user presses the "submit" button, I want to disable the submit button. If the user cancelled/stopped the submission while it's loading, the submit button will still be disabled (should be re-enabled if submission was cancelled/stopped).

---

Edit/Rephrase - 16th Dec 2013:

My problem is similar to this: Is there a jQuery event that I can monitor if form submission is cancelled?

For example, I have this form:

<form method="post" enctype="multipart/form-data">
    <input type="file" name="imginput" value=""/>
    <input type="text" name="textinput" value=""/>
    <input type="button" id="submitbtn" value="Submit"/>
</form>

Here's the problem scenario:

A newbie user fills up the form, then double-clicks the submit button. The same form values are inserted into the server twice!

Trying to Achieve:

I want to disable the submit button on click with $('#submitbtn').bind('click', function() { $(this).attr('disabled','disabled'); $(this).prop('disabled', true); });, which solves the problem but creates another problem: if the user clicked "esc" or stopped the browser while the form is still submitting, the submit button would still be disabled and the user cannot re-submit the form any more, I want to re-enable the submit button as soon as the "submission process" is cancelled. Is there a way to achieve this? Something like: $(window).onStop(function() { ... }); ? or a way to indicate that the submission process has been interrupted (or still running)?

Notes:

• Looking for client-side (javascript or jquery) solution. I know it can be solved easily with server-side checking for identical entries, but I'm not interested in server-side solution.
• Problem can be solved with XHR (ajax/json) bindings (like onSuccess, onFailure, etc).. but in this case, I'm using a normal post, not XHR, so please exclude XHR from your answer.
• Solution has to solve the problem at least for the 5 major browsers (IE, FF, Chrome, Safari, Opera).
• Someone may suggest that we bind "keypress" for the "esc" button, so when the user press "esc" we re-enable the submit button. That's good, but that's half-solution. What if the user stopped the "submission process" by the stop button of the browser, is there a way to indicate that this stop button has been clicked?

Answer 1

Finally, this question actually breaks down the complex problem and can thus be addressed in parts, as it should be. First, let's get the elephant out of the room:

• there is no cross browser solution that detects when the user hits a stop/(ref) button

I actually looked this up for a while and couldn't find how to do it but maybe someone can provide an answer to that and enlighten us both. Now, let's get the 2nd elephant out of the room.

• No Ajax requests allowed (for some reason). Once the user has hit the submit button and the actual submit event triggers away, we are STUCK

It's a fact that we being able to do things while some request is being processed is what is called Asynchronous (like the first "A" in "Ajax"). Let's see the 3rd elephant

• I have dumb/inexperienced/clickety-clackety/abusers users that can create inconsistencies on the server (ie: unwanted duplicates) by accident. We should provide a mechanism to impede such event.

Disabling buttons is, of course, the easiest solution in this dilemma. We capture the submit, put in a line to disable any further submit events from that form. Done. May the next elephant come in?

• The process has begun, the user sees the progress indicator spinning and realizes he just fucked up. He wants to stop it, HELL! he needs to stop it.

Problem, the user doesn't know (and he sure as hell shouldn't need to know) if the server already has complete headers and is processing the request. The server can listen to see if the client aborted but...

• The user hit the stop button! did the server process the request? did the server dump it? did my data hit the database? oh, now I have a disabled form that I can't use anymore, and I don't know if what I did had consequences. How about a refresh?

Now your issue has a bunch of big holes in it that are worsened by the fact that YOU do NOT want your requests to be ASYNCHRONOUS, AND there is NO WAY to listen for browser.onStopreliably.

My Answer

Think things differently.

• You are afraid of inconsistencies. Solution: disable submit events after the first

• Your users are dumb/inexperienced. Solution: big red label Warning: do not press the stop button during the process, or navigate away from the page until the request has completed.

• Your users are worried. Solution: add a caveat You may edit your post/info in another page once the request has completed. (some instructions to find the edit page)

• Your server (or slow connection) is taking too long to finish and the user may be impatient. Solution: set a timeout event before triggering the submission that will... but wait! the request is Synchronous which means nothing else can be done until it's finished. Dear User: this process may take a while. If after X mins you have not been redirected to this/page.html please... (do something/more instructions)

• Take all this advice and start using Ajax if you want higher levels of interactivity, educate your users on the hazards of trying to abort requests and give them options to edit afterwards.

• Follow examples of other services. Many companies warn very strongly during payment procedures to be patient until the process has finished and add some instructions just in case something goes wrong and the user is worried.

• Consider adding limitations to the interactivity, some processes are just not meant to be interactive (payments, unique entries...)

• If you are worried that a user will leave himself stranded on a disabled form then add some info to him. If you tried to stop the procedure please follow this link to see if it was processed, if it wasn't you will be redirected to this form again (you may want to save the users form data so he doesn't have to start over)

Answer 2

Internet Explorer has a document.onstop event that is fired, but other browsers don't seem to support that. Note that it's fired when the user clicks Stop or hits Esc, OR if the user navigates to another page during page load, which has the same effect.

I don't believe there is a reliable way to trigger an event on clicking Stop in other browsers. Perhaps it would be possible to do something like: keeping the connection to the server open (as in the Comet approach), streaming some sort of keep-alive down the connection, and detecting if the stream ends (as I assume it would if the Stop button were clicked).

From: Any javascript event occuring when user clicks Stop load button?