How to detect submit abort / stop button?

[sliffy]

Hi all,

While I understand there is no stop button handler, I do desire a way to know if a form submission was aborted.

When I submit my page, I lock down all of the controls so no further editing is allowed. If aborted (via ESC key, stop button, etc.) I'd like the page to open again.

Is this possible?

I thought that perhaps onAbort would be called if I displayed an animated GIF but that is not the case (and rightfully so; makes sense).

Any ideas? Thanks!

[sliffy]

Also, I was thinking there would be a way to check something in Javascript with intervals...

setInterval('so meFunc()', 500);

function someFunc() {
/*
Check a property of window? document? form? navigator?
*/
}

[kovik]

If someone stops a form's submission, they have to deal with it, not you. You shouldn't worry about it.

If you're really concerned, don't disable the submission button.

[sliffy]

Hi V,

Much agreed.

The issue is that when the form submit is stopped, none of the data has been posted to the server and the entire form is locked down, so they have to refresh the page - losing all of their data. I have to lock down the form so that during a long submit operation, people don't edit the fields and get confused when the additional data disappears (this happens, trust me).

While you and I can easily agree (and we do) that pressing "stop" takes you out of the flow of our web apps, to users the data is still "there" in front of them - why can't I fix my mistake and press submit again?

While it pains me to say it, I'm prepared to use the document.stop handler in IE.

I spent 4 hours last night looking for a more portable solution. My only discovery was that Firefox sends the ESC key to the window so I can catch that.

[gits]

hi ...

i think you may use ajax instead of a 'normal' form-submit. with the ajax-call you pass the data to the server and when you get the response you reenable your interface. so you have the control about the request. but i must admit that i don't know exactly whether the request may be stopped with ESC or the stop-button ... but if so you may get a response (request-status != 200) that is quite cool to handle ;) ...

kind regards

[sliffy]

Many thanks for the reply G :)

Because this form may contain a file upload (the lengthy operation which is typically aborted with the "stop" button), switching to an Ajax solution adds a lot of complexity.

I was hoping there would be and XHR-like property somewhere in window, navigator or document that I could check to see what the status of the request was.

Argh.

[kovik]

Basically, just don't disable the button. Sometimes, your server response is slow and if they abort and try again, it'll be faster (and most users know this). Disabling the button isn't generally a recommended practice, as it inhibits usability.

[gits]

Basically, just don't disable the button. Sometimes, your server response is slow and if they abort and try again, it'll be faster (and most users know this). Disabling the button isn't generally a recommended practice, as it inhibits usability.

that depends strongly to the application ... and in case of using ajax-techniques it is evident to consider that option in cases where you send expensive requests (until the inerface is responsive during the request) ... exmp: send a request (may be to save something) ... in that case you disable the save-button until you get response (success or failure) ... the user notices that something happens, and you certainly dont want him to send that again ... during the first save-operation ... of course this creates 'quasi'-synchron-handling of async requests but when you have things that lasts 1 minute (and we have that here - due to processing mass-data in an intranet-application) you don't want the user to repeatedly send that request ... traffic, server-load, db-load ... etc.

so it improves usability - in such a case ...

but for traditional webapps you are right of course ...

kind regards

[kovik]

Actually, that would improve things on the server's end rather than the client's. As developers, we naturally care more about our servers and our bandwidth than the client does, so we're meant to protect it. However, in terms of usability, it's better to work in favor of the user rather than the server. For example, if the user was making a payment and hit the submit button twice, we'd want to detect to the extra click and submission and cancel the submission altogether rather than submit it twice.

The best thing you could do in terms of usability is make a very obvious "Processing " message displayed for the user so they are aware, but if they press the stop button, they can always retry.

[gits]

;) i know what you mean ... but isn't it clientside usability too, when we are able to avoid double-payment through simple disabling of controls that the user shouldn't use at the moment? ... it is the same thing when we have chained menulists or something like that ... guiding the user with available actions/options.

assuming my mentioned example above: start a long, expensive request, start-it again ... they are handled parallel ... when using ajax ... every request handles the response ... may be altering something within the interface ... first request returns, or the second one ... is doing something with our ui ... later the next one returns ... probably the user worked with the ui after the first returning request ... and the second returning request handles the same things as the first one did ... and thus may be it resets the interface again to the state that the first one did. so avoiding 'double'-actions is in favour of the user ...

may be we should start a new thread on that? its getting besides the original problem ;))

kind regards