Disable a form submission link during validation?

[kschneider]

Assume there's a form with it's action attribute all set to post to a
URL, but without a submit control. Form submission is done via a link
and I want to prevent the classic "double submit". Ignoring the server
side of things, does anyone see any holes with the following script? It
seems to work, but I'd appreciate other eyes on it. Maybe a
try/catch/finally wrapper of some sort to be sure the link is
re-enabled in the face of an exception. I understand there are (many)
other ways to do this (e.g. temporarily "remove" the link), but I'm
mostly curious about the
this.onclick=falseFn/this.onclick=arguments.callee combo and any
potential gotchas. Thanks.

function falseFn() {
return false;
}

// this is the onclick handler for the link
function submitLinkOnclick() {
this.onclick = falseFn; // disable link to prevent double-submit

var isOkToSubmit = false;
var form = document.getElementById("form");

// logic to see if it's OK to submit form (set isOkToSubmit = true)

if (isOkToSubmit) {
form.submit();
} else {
alert("blah blah blah");
this.onclick = arguments.callee; // re-enable link
}

return false;
}

 

[RobG]

Assume there's a form with it's action attribute all set to post to a
URL, but without a submit control. Form submission is done via a link
and I want to prevent the classic "double submit". Ignoring the server
side of things, does anyone see any holes with the following script? It
seems to work, but I'd appreciate other eyes on it. Maybe a
try/catch/finally wrapper of some sort to be sure the link is
re-enabled in the face of an exception. I understand there are (many)
other ways to do this (e.g. temporarily "remove" the link), but I'm
mostly curious about the
this.onclick=falseFn/this.onclick=arguments.callee combo and any
potential gotchas. Thanks.

Two: if the user has JavaScript disabled or not available, they can't
submit the form.

The second (and probably bigger one) is that script execution on the
client is unreliable. You may end up with the form being submitted
multiple times anyway, or the user's first attempt to submit may not
work or be cancelled and your script may block subsequent submissions
unreasonably.

function falseFn() {
return false;
}

// this is the onclick handler for the link
function submitLinkOnclick() {
this.onclick = falseFn; // disable link to prevent double-submit

In order for 'this' to refer to the element on which the onclick
handler has been placed, you must be attaching the function dynamically
using something like:

theLink.onclick = submitLinkOnclick;

var isOkToSubmit = false;
var form = document.getElementById("form");

I'm not a big fan of having an element with an ID the same as the tag
name, then also having a local variable with the same name - what
'form' refers to starts to get confusing. IE will add a 'form'
property to the global object too.

// logic to see if it's OK to submit form (set isOkToSubmit = true)

if (isOkToSubmit) {

Since you changed isOkToSubmit to false above, this will always return
false and the form will never submit.

form.submit();
} else {
alert("blah blah blah");
this.onclick = arguments.callee; // re-enable link

So you will always re-set the onclick to the current function. At what
point were you going to set it to falseFn?

}

return false;
}

The whole approach seems flawed. If you want to try something on the
client, put a submit button in the form and have a global variable (or
the value of some hidden form field) set to 'not submitted' (or false
or whatever). When the form is submitted, check the value to determine
whether to submit the form or not and change the value of the
variable/field to 'submitted' (or true or whatever). The following
example uses the form name to add a property to a global object so you
can keep track of multiple forms:

<script type="text/javascript">

var submittedForms = {};

function checkSubmit(formRef){
if (formRef.name in submittedForms){
alert('submitted');
return false;
}
submittedForms[formRef.name] = true; // Any value will do
}
</script>

<form name="formA" action=""
onsubmit="return checkSubmit(this);">
<!-- rest of form -->.
<input type="submit">
</form>


But it's not a very reliable method of stopping multiple submissions.

 

[kschneider]

Rob,

Thanks for looking it over. See inline.

Two: if the user has JavaScript disabled or not available, they can't
submit the form.

Sure, understood.

The second (and probably bigger one) is that script execution on the
client is unreliable. You may end up with the form being submitted
multiple times anyway, or the user's first attempt to submit may not
work or be cancelled and your script may block subsequent submissions
unreasonably.

I'm not sure I follow. In what way is script execution unreliable? Do
you just mean that JavaScript could be disabled? Under what conditions
would the form be submitted multiple times?

In order for 'this' to refer to the element on which the onclick
handler has been placed, you must be attaching the function dynamically
using something like:

theLink.onclick = submitLinkOnclick;
Right.


I'm not a big fan of having an element with an ID the same as the tag
name, then also having a local variable with the same name - what
'form' refers to starts to get confusing. IE will add a 'form'
property to the global object too.

Neither am I, it was just something quick to type for the example.

Since you changed isOkToSubmit to false above, this will always return
false and the form will never submit.

The comment was supposed to indicate that there would be logic in the
"real" function to determine if it's OK to submit the form.

So you will always re-set the onclick to the current function. At what
point were you going to set it to falseFn?

It's the first thing that the function does.

}

return false;
}

The whole approach seems flawed. If you want to try something on the
client, put a submit button in the form and have a global variable (or
the value of some hidden form field) set to 'not submitted' (or false
or whatever). When the form is submitted, check the value to determine
whether to submit the form or not and change the value of the
variable/field to 'submitted' (or true or whatever). The following
example uses the form name to add a property to a global object so you
can keep track of multiple forms:

<script type="text/javascript">

var submittedForms = {};

function checkSubmit(formRef){
if (formRef.name in submittedForms){
alert('submitted');
return false;
}
submittedForms[formRef.name] = true; // Any value will do
}
</script>

<form name="formA" action=""
onsubmit="return checkSubmit(this);">
<!-- rest of form -->.
<input type="submit">
</form>


But it's not a very reliable method of stopping multiple submissions.

I don't have the option of replacing the link with a form control to do
the submission. In terms of preventing multiple submissions via the
link, do you see any technical issues with the
this.onclick=falseFn/this.onclick=arguments.callee combo?

 

[Randy Webb]

(e-mail address removed) said the following on 7/26/2006 8:44 AM:

I'm not sure I follow. In what way is script execution unreliable? Do
you just mean that JavaScript could be disabled? Under what conditions
would the form be submitted multiple times?

The user could have it disabled, it could not be present at all (my
cellphone doesn't support JS), or, an error in the code of the page
could cause JS to stop executing.

The comment was supposed to indicate that there would be logic in the
"real" function to determine if it's OK to submit the form.

That is one of the flaws of "typing an example" whereby the code that is
being reviewed isn't even close to a real example's code.

 

[kschneider]

(e-mail address removed) said the following on 7/26/2006 8:44 AM:

The user could have it disabled, it could not be present at all (my
cellphone doesn't support JS), or, an error in the code of the page
could cause JS to stop executing.

Disabled or not supported doesn't seem to be a concern for this app.
Not my call, just the reality of how the app is being developed for its
target environment. My only real concern is the implementation of the
submitLinkOnclick function. Assuming that the function is actually
invoked, are there any technical issues with it? I haven't come across
the approach of using this.onclick = falseFn/this.onclick =
arguments.callee to disable a link during processing, so I'm curious
about whether it's actually viable. One issue I can imagine, as noted
in the original post, is that it might make sense to use
try/catch/finally so that the link is re-enabled in case an exception
is thrown during the validation logic.

That is one of the flaws of "typing an example" whereby the code that is
being reviewed isn't even close to a real example's code.

I suppose I could have used something like:

isOkToSubmit = validateForm(form);

without supplying the details of the validateForm function, but other
than that, the example actually is pretty close to the real code.