Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #25860 > unrolled thread

Stopping Multi-submits ?

Back to article view | Back to comp.lang.javascript

Contents

  Stopping Multi-submits ? "Mel Smith" <syntel@cox.net> - 2014-09-23 08:58 -0600
    Re: Stopping Multi-submits ? Cezary Tomczyk <cezary.tomczyk@gmail.com> - 2014-09-23 20:22 +0200
      Re: Stopping Multi-submits ? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2014-09-24 02:50 +0200
    Re: Stopping Multi-submits ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-09-23 20:31 +0200
      Re: Stopping Multi-submits ? "Mel Smith" <syntel@cox.net> - 2014-09-23 16:27 -0600
        Re: Stopping Multi-submits ? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2014-09-24 00:54 +0200
          Re: Stopping Multi-submits ? "Mel Smith" <syntel@cox.net> - 2014-09-24 08:24 -0600

#25860 — Stopping Multi-submits ?

Hi:

Situation:

    To forestall a user multi-clicking on a submit button, I use JS code 
similar to the following:

        getobj("mybuttonid").disabled=true ;
        getobj("myloginid").submit() ;

        (where the getobj() function is simply my short way of using 
document.getElementById()  )

Result:
    If my server response is very slow, my user hitting the submit button 
repeatedly will *not* result in successive submits because the submit button 
is now disabled.

Problem:

    In IE11 (at least), after the new page arrives, if the user decides to 
use the 'back arrow' to re-load the previous page, then that submit button 
is *still* disabled, when I wish it to be enabled and ready for another 
submit

Question:

    How do I restrain multiple submits, *but* allow submits again after a 
new page has arrived, and then the user 'arrows' back to the previous page 
(or pages).

    (btw, I tried putting the re-enabling code in the onload event, but I 
guess that the onload code doesn't get activated if the user simply uses his 
back-arrow to get his previous page ?? )

Thanks.

-Mel Smith
 

[toc] | [next] | [standalone]

#25861

On 2014-09-23 16:58, Mel Smith wrote:
[...]
> Problem:
>
>      In IE11 (at least), after the new page arrives, if the user decides to
> use the 'back arrow' to re-load the previous page, then that submit button
> is *still* disabled, when I wish it to be enabled and ready for another
> submit
>
> Question:
>
>      How do I restrain multiple submits, *but* allow submits again after a
> new page has arrived, and then the user 'arrows' back to the previous page
> (or pages).
[...]

Maybe do not disable the button, but instead of that when user clicks on 
the button set some state, e.g.:

var submitState = false;

to "true" and when the user clicks on button again just check that state 
and do the right action, e.g. if the state == true then show the message 
for the user that his "request is still in progress".

-- 
Cezary Tomczyk
http://www.ctomczyk.pl/

[toc] | [prev] | [next] | [standalone]

#25865

Cezary Tomczyk wrote:

> On 2014-09-23 16:58, Mel Smith wrote:
> [...]
>> Problem:
>>
>>      In IE11 (at least), after the new page arrives, if the user decides
>>      to use the 'back arrow' to re-load the previous page, then that
>>      submit button is *still* disabled, when I wish it to be enabled and
>>      ready for another submit
>>
>> Question:
>>
>>      How do I restrain multiple submits, *but* allow submits again after
>>      a new page has arrived, and then the user 'arrows' back to the
>>      previous page (or pages).
> [...]
> 
> Maybe do not disable the button, but instead of that when user clicks on
> the button set some state, e.g.:
> 
> var submitState = false;
> 
> to "true" and when the user clicks on button again just check that state
> and do the right action, e.g. if the state == true then show the message
> for the user that his "request is still in progress".

However, there is no guarantee that, using the Back feature, the pre-
existing environment will not be sufficiently restored.  A sufficiently 
reliable client-side possibility are cookies or Local/Session Storage 
instead; IOW, anything that is *not* tied to the document or view.  HTML5 
Push State and equivalents come to mind as well even though they are tied to 
the view.

Eventually, this can only be solved reliably server-side, by generating 
forms that are not cached (although this could be ignored by the UA as 
well), and submit tokens that are generated once, stored in a server-side 
session, and expire on successful form submission (anything else could 
result in accidental submission if the Forward feature is used 
subsequently).  This is also the recommended usability and security measure, 
given that client-side script code need not be executed.

It is possible to use XHR to improve the user experience, though: the 
submission of forms whose token has expired can be cancelled in advance.  
The negligible extra cost of this measure can result in a significant 
reduction of server load, depending on how much data is being sent when the 
submission is successful.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not Cc: me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#25862

"Mel Smith" <syntel@cox.net> wrote on 23 sep 2014 in comp.lang.javascript:

> Hi:
> 
> Situation:
> 
>     To forestall a user multi-clicking on a submit button, I use JS code
> similar to the following:
> 
>         getobj("mybuttonid").disabled=true ;
>         getobj("myloginid").submit() ;
> 
>         (where the getobj() function is simply my short way of using 
> document.getElementById()  )
> 
> Result:
>     If my server response is very slow, my user hitting the submit
>     button 
> repeatedly will *not* result in successive submits because the submit
> button is now disabled.
> 
> Problem:
> 
>     In IE11 (at least), after the new page arrives, if the user decides
>     to 
> use the 'back arrow' to re-load the previous page, then that submit
> button is *still* disabled, when I wish it to be enabled and ready for
> another submit
> 
> Question:
> 
>     How do I restrain multiple submits, *but* allow submits again after
>     a 
> new page has arrived, and then the user 'arrows' back to the previous
> page (or pages).
> 
>     (btw, I tried putting the re-enabling code in the onload event, but
>     I 
> guess that the onload code doesn't get activated if the user simply uses
> his back-arrow to get his previous page ?? )

If you leave the page by form-submission,
clientside javascript cannot help you on this page.

Use 
<form onsubmit='return mySubmit(this)' ....

and return false to prohibit a second submit onpage.

Alternatively you can return false all the time 
and use myForm.submit() where needed. 

To prevent submission on another page, 
or on a reload of he same page,
use serverside code.

To prevent the effects of a resubmission after backspacing,
[which you were not planning to do, methinks]
you would have to block the results serverside.

=====================

If you want to stay on the page after submission
use a <form target='...' 
and perhaps let that target be an [hidden?] iframe on page.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25863

Cezary & Evertjan:

    Thanks you both for your responses and suggestions.

    I'll study them carefully tomorrow --- after golf tomorrow afternoon :))

-Mel

[toc] | [prev] | [next] | [standalone]

#25864

"Mel Smith" <syntel@cox.net> wrote on 24 sep 2014 in comp.lang.javascript:

> Cezary & Evertjan:
> 
>     Thanks you both for your responses and suggestions.
> 
>     I'll study them carefully tomorrow --- after golf tomorrow afternoon
>     :)) 

Mel,

I don't know what "tomorrow afternoon" exactly means,
not knowing where you live on this planet.

Golf I have heard of, 
that being a game the Scots stole from the Frisian game of "kolf",
and changing that to the more rough highland environment and the kilt 
culture. 

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#25866

Evertjan said:

> Mel,
>
> I don't know what "tomorrow afternoon" exactly means,
> not knowing where you live on this planet.
>

    Western Canada !  and (during the winter) south-western United States)

> Golf I have heard of,
> that being a game the Scots stole from the Frisian game of "kolf",
> and changing that to the more rough highland environment and the kilt
> culture.

      No kilts today -- its only 12C outside as I'm about to leave

-Mel

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web