Netscape7.1 order of onchange()/onsubmit() events WRONG

Discussion in 'Javascript' started by Lynn, Sep 13, 2004.

  1. Lynn

    Lynn Guest

    I have been going round in circles trying to get this to work.....

    I have a form with many fields, each with an onchange() event. There
    is also an onclick event on the form Submit button.
    If one changes a field and goes immediately to the Submit button, then
    the onsubmit() function gets called before the onchange()function.
    This leads to the field not getting validated correctly. If you go to
    any other field in the form, but not the submit button, it is fine.
    This problem is only in Netscape7.1, IE is absolutely fine.


    Any help greatly appreciated! Thanks in advance,
    Lynn
     
    Lynn, Sep 13, 2004
    #1
    1. Advertisements

  2. I can't replicate this in Netscape 7.2, so if it is a bug, it's been
    fixed. Could you show a simple version of the code and HTML you're using,
    which still displays the problem?

    Mike
     
    Michael Winter, Sep 13, 2004
    #2
    1. Advertisements

  3. When the submit button is pressed, create a timeout
    {window.validate_flag=false; setTimeout("submit_to()",200)} event and
    wait about 200ms before running the code. Have your validation code
    set a flag that the if there is a validation block. Have the timeout
    script read for the flag being set and handle as necessary.
     
    Java script Dude, Sep 14, 2004
    #3
  4. JRS: In article <1095232552.cZc+BJ+L2P98owmOEXcEjA@teranews>, dated
    Wed, 15 Sep 2004 01:15:59, seen in =?UTF-
    Nonsense. Some pages are only possible with scripting running; and some
    are designed to be used client-side without post-delivery support from a
    server. Never use "never" unless you really mean it.

    Consider, for example, <URL:http://www.merlyn.demon.co.uk/js-clndr.htm>,
    which has no significant content (bar the links to other pages) without
    script running.

    If there is a server, and if the correct operation is of real interest
    to server-side people, then there should be server-side verification.
    But if spoofing has no effect other than on the spoofer, server-side
    verification is not needed. Consider the situation where the
    calculating engine for js-clndr.htm was server-side : a user enters
    spoofed data and gets spoofed results - as is appropriate. (It may be
    necessary to trap data that would harm the server, for example by
    hogging resources.)


    While Web pages and javascript are often used in support of business
    transactions, it is a mistake to assume that they always are.
     
    Dr John Stockton, Sep 15, 2004
    #4
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.