event handler problem in large complex form

[Arthur Rusdell-Wilson]

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.

does any one else have this problem, and is there a work-round?

--
Arthur Rusdell-Wilson

[Martin Honnen]

Arthur Rusdell-Wilson wrote:

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.

Does that happen with one particular browser? Or with different ones?
Is there perhaps a script error happening so that the return false
statement is not reached?

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Grant Wagner]

"Arthur Rusdell-Wilson" <ar****@kitekon sultants.co.uk> wrote in message
news:db******** ***********@new s.demon.co.uk.. .

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.

does any one else have this problem, and is there a work-round?

--
Arthur Rusdell-Wilson

It's likely you aren't returning the value returned from the JavaScript
function to the event:

<form ... onsubmit="valid ate(this);">

The above won't ever stop the form submission even if the function is
defined as:

function validate() { return false; }

In order for the function to prevent form submission, you must return
the value to the event:

<form ... onsubmit="retur n validate(this); ">

If you have this, and you've verified that false (not "false") is
actually being returned (using <form ...
onsubmit="alert (validate(this) );">), then it's a browser implementation
bug and there won't be any work-around short of changing browsers.

I doubt very much it is a browser implementation bug, and instead one of
the two possibilities I listed:

1) you aren't returning the value to the event
2) you are returning the string "false" instead of the boolean false

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[VK]

> I find that in a large form (especially if there is a table within the

form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.
does any one else have this problem, and is there a work-round?

I encountered it several times (but very rarely). It was always
connected with too long delay before you approve/cancel the bubble.
Always was helped by optimising the code (so your decision would come
out quickly). One of undescribed yet ghosts of JavaScript (like orphane
scripts). Never happens on primitive events like onclick/mousevove/etc.

Form submission / window closure / unload - the most probable places to
meet them. I call this "speedy bubbles", you may too if you want :-)

I guess it's a part of interface protection, so you couldn't lock user
on one page by simply putting each onsubmit/onbeforeunload/onload on
some endless process. Just an amateur guess...

Get the fat out of you script, it should help right away. Unless the
problem is im something else.

[Danny]

First off, give your page a document type, a DTD, say html4.1 strict dtd
and then validate, chances are your page is malformed and Form is split by
some unclosed opened element in it:

<form> <input> <input> <table> .....</form> </table>
really in quirk mode will cut off the 1st Form at the <table> part as it
never closed IN IT, and more than likely will render a 2nd orphan Form
from the fragment, cutting off any children from the 1st Form. I've seen
such and JS does report that because you're eventing an element that's cut
off from the Parent element you think it belongs to.
<FORM> <input> <button> <select></select> <ANYELEMEENT> .....
</ANYELEMENT></form>

is the proper way and will keep all Form children with its parent.
Danny

On Tue, 12 Jul 2005 08:55:13 -0700, Arthur Rusdell-Wilson
<ar****@kitekon sultants.co.uk> wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

[Arthur Rusdell-Wilson]

I think you are probably right. I worked on that assumption, and everything
now works ok. However I did find one or two other little bugs as I was doing
this, so not absolutely sure. Anyway, I have an approach now for avoiding
this problem in the future.

--
Arthur Rusdell-Wilson
"VK" <sc**********@y ahoo.com> wrote in message
news:11******** *************@g 49g2000cwa.goog legroups.com...

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.
does any one else have this problem, and is there a work-round?

I encountered it several times (but very rarely). It was always
connected with too long delay before you approve/cancel the bubble.
Always was helped by optimising the code (so your decision would come
out quickly). One of undescribed yet ghosts of JavaScript (like orphane
scripts). Never happens on primitive events like onclick/mousevove/etc.

Form submission / window closure / unload - the most probable places to
meet them. I call this "speedy bubbles", you may too if you want :-)

I guess it's a part of interface protection, so you couldn't lock user
on one page by simply putting each onsubmit/onbeforeunload/onload on
some endless process. Just an amateur guess...

Get the fat out of you script, it should help right away. Unless the
problem is im something else.

[Arthur Rusdell-Wilson]

See my reply to VK

--
Arthur, on behalf of Kite Konsultants

"Martin Honnen" <ma*******@yaho o.de> wrote in message
news:42******** *************** @newsread2.arco r-online.net...

Arthur Rusdell-Wilson wrote:

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.

Does that happen with one particular browser? Or with different ones?
Is there perhaps a script error happening so that the return false
statement is not reached?

--

Martin Honnen
http://JavaScript.FAQTs.com/

[Arthur Rusdell-Wilson]

The problems you identify were not those that I had. I believe VK has the
answer, see my reply to his.

--
Arthur, on behalf of Kite Konsultants

"Grant Wagner" <gw*****@agrico reunited.com> wrote in message
news:0m******** ******@news2.mt s.net...

"Arthur Rusdell-Wilson" <ar****@kitekon sultants.co.uk> wrote in message
news:db******** ***********@new s.demon.co.uk.. .

I find that in a large form (especially if there is a table within the
form?) that the form is submitted to my server-side script even when a
JavaScript 'onsubmit' event handler returns 'false'.

does any one else have this problem, and is there a work-round?

--
Arthur Rusdell-Wilson

It's likely you aren't returning the value returned from the JavaScript
function to the event:

<form ... onsubmit="valid ate(this);">

The above won't ever stop the form submission even if the function is
defined as:

function validate() { return false; }

In order for the function to prevent form submission, you must return
the value to the event:

<form ... onsubmit="retur n validate(this); ">

If you have this, and you've verified that false (not "false") is
actually being returned (using <form ...
onsubmit="alert (validate(this) );">), then it's a browser implementation
bug and there won't be any work-around short of changing browsers.

I doubt very much it is a browser implementation bug, and instead one of
the two possibilities I listed:

1) you aren't returning the value to the event
2) you are returning the string "false" instead of the boolean false

--
Grant Wagner <gw*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Arthur Rusdell-Wilson]

Thanks, this was not the problem. See my reply to VK

--
Arthur, on behalf of Kite Konsultants

"Danny" <da*******@blue bottle.com> wrote in message
news:1121224720 .43ad5d22940ff6 a748c56a48f7a65 572@teranews...

First off, give your page a document type, a DTD, say html4.1 strict dtd
and then validate, chances are your page is malformed and Form is split by
some unclosed opened element in it:

<form> <input> <input> <table> .....</form> </table>
really in quirk mode will cut off the 1st Form at the <table> part as it
never closed IN IT, and more than likely will render a 2nd orphan Form
from the fragment, cutting off any children from the 1st Form. I've seen such and JS does report that because you're eventing an element that's cut
off from the Parent element you think it belongs to.
<FORM> <input> <button> <select></select> <ANYELEMEENT> .....
</ANYELEMENT></form>

is the proper way and will keep all Form children with its parent.
Danny

On Tue, 12 Jul 2005 08:55:13 -0700, Arthur Rusdell-Wilson
<ar****@kitekon sultants.co.uk> wrote:

--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/