Problem with submit in IE and FF

Discussion in 'Javascript' started by szimek, Feb 11, 2008.

  1. szimek

    szimek Guest

    Hi,

    I've got very sick IE-only app and I'm trying to make it FF
    compatible. Here's one of maaany problems.

    There's a link (it's actually a span element with onclick event
    handler) that triggers javascript function that submits a hidden form.
    This form action attribute is set to "main.jsp".

    In IE after clicking this button, the onclick event is later passed to
    the body element, but there's nothing interesting going on. In the
    main.jsp file there's "parent.document.location=logout_page.jsp" js
    code that redirects it to the logout page.

    In FF the event is also passed to the body element, but the whole apge
    just halts with the wait cursor. I've put the "debugger" keyword right
    before the js code mentioned before (document.location) and the IE
    debugger halts on it, but the Firebug doesn't see it and the page just
    hangs.

    It works fine in Opera 9.23...

    I have no idea how the main.jsp is generated, but is there some way to
    break on the first line of the generated main.jsp that the form action
    points to? This way I could see if the generated FF version differs
    from IE version. I really have no other idea how to solve this
    problem.

    Or maybe there's a way to see exactly in IE and FF what data is send
    by this form (it's using POST) and if it's different in any way.

    Thanks in advance for any suggestions
    szimek, Feb 11, 2008
    #1
    1. Advertising

  2. szimek wrote:
    > I've got very sick IE-only app and I'm trying to make it FF
    > compatible.


    Error #1: Optimizing for a limited set of browsers instead of applying Web
    standards in order to optimize for a wider set of sufficiently standards
    compliant user agents.

    > Here's one of maaany problems.
    >
    > There's a link (it's actually a span element with onclick event
    > handler) that triggers javascript function that submits a hidden form.


    Error #2: Misusing HTML elements, with a result that does not degrade
    gracefully. Use a submit button instead.

    What is a "hidden form" anyway?

    > This form action attribute is set to "main.jsp".


    Irrelevant. JSP means JavaServer Pages. Java != JavaScript.

    > In IE after clicking this button, the onclick event is later passed to
    > the body element, but there's nothing interesting going on.


    "Passed to the body element"?

    The important information that you omitted is: What do you expect to be
    "going on"?

    http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork

    > In the main.jsp file there's "parent.document.location=logout_page.jsp" js
    > code that redirects it to the logout page.


    That's highly unlikely. It has to be

    parent.document.location = "logout_page.jsp";

    for a reasonable chance to work. It should be:

    window.parent.location = "logout_page.jsp";

    (document.location is deprecated since ca. 11.5 years now [JavaScript 1.1].)

    However, that is probably irrelevant as your problem occurs before execution
    reaches that line.

    > In FF the event is also passed to the body element, but the whole apge
    > just halts with the wait cursor.


    Talk is cheap. Show some code.
    -- Linus Torvalds

    > I've put the "debugger" keyword right before the js code mentioned before
    > (document.location) and the IE debugger halts on it, but the Firebug
    > doesn't see it and the page just hangs.


    Probably not.

    > It works fine in Opera 9.23...


    The current version is 9.25.

    > I have no idea how the main.jsp is generated, but is there some way to
    > break on the first line of the generated main.jsp that the form action
    > points to? This way I could see if the generated FF version differs
    > from IE version. I really have no other idea how to solve this
    > problem.


    You appear to be remarkably clueless about the technologies you are using.
    JSP only generates a markup document from the HTTP request for the HTTP
    response and provided that is an (X)HTML document you can set a breakpoint
    within the `script' element in the response document with Firebug, without
    having to edit that document.

    > Or maybe there's a way to see exactly in IE and FF what data is send
    > by this form (it's using POST) and if it's different in any way.


    Either server-side (displaying the request variables via JSP) or in Firefox
    with the LiveHTTPHeaders extension. But that is not going to solve your
    immediate problem.


    PointedEars
    --
    Anyone who slaps a 'this page is best viewed with Browser X' label on
    a Web page appears to be yearning for the bad old days, before the Web,
    when you had very little chance of reading a document written on another
    computer, another word processor, or another network. -- Tim Berners-Lee
    Thomas 'PointedEars' Lahn, Feb 15, 2008
    #2
    1. Advertising

  3. szimek

    szimek Guest

    On 15 Lut, 01:23, Thomas 'PointedEars' Lahn <>
    wrote:
    > szimek wrote:
    > > I've got very sick IE-only app and I'm trying to make it FF
    > > compatible.

    >
    > Error #1: Optimizing for a limited set of browsers instead of applying Web
    > standards in order to optimize for a wider set of sufficiently standards
    > compliant user agents.
    >
    > > Here's one of maaany problems.

    >
    > > There's a link (it's actually a span element with onclick event
    > > handler) that triggers javascript function that submits a hidden form.

    >
    > Error #2: Misusing HTML elements, with a result that does not degrade
    > gracefully.  Use a submit button instead.
    >
    > What is a "hidden form" anyway?
    >
    > > This form action attribute is set to "main.jsp".

    >
    > Irrelevant.  JSP means JavaServer Pages.  Java != JavaScript.
    >
    > > In IE after clicking this button, the onclick event is later passed to
    > > the body element, but there's nothing interesting going on.

    >
    > "Passed to the body element"?
    >
    > The important information that you omitted is: What do you expect to be
    > "going on"?
    >
    > http://www.jibbering.com/faq/faq_notes/clj_posts.html#ps1DontWork
    >
    > > In the main.jsp file there's "parent.document.location=logout_page.jsp" js
    > > code that redirects it to the logout page.

    >
    > That's highly unlikely.  It has to be
    >
    >   parent.document.location = "logout_page.jsp";
    >
    > for a reasonable chance to work.  It should be:
    >
    >   window.parent.location = "logout_page.jsp";
    >
    > (document.location is deprecated since ca. 11.5 years now [JavaScript 1.1]..)
    >
    > However, that is probably irrelevant as your problem occurs before execution
    > reaches that line.
    >
    > > In FF the event is also passed to the body element, but the whole apge
    > > just halts with the wait cursor.

    >
    > Talk is cheap.  Show some code.
    >   -- Linus Torvalds
    >
    > > I've put the "debugger" keyword right before the js code mentioned before
    > > (document.location) and the IE debugger halts on it, but the Firebug
    > > doesn't see it and the page just hangs.

    >
    > Probably not.
    >
    > > It works fine in Opera 9.23...

    >
    > The current version is 9.25.
    >
    > > I have no idea how the main.jsp is generated, but is there some way to
    > > break on the first line of the generated main.jsp that the form action
    > > points to? This way I could see if the generated FF version differs
    > > from IE version. I really have no other idea how to solve this
    > > problem.

    >
    > You appear to be remarkably clueless about the technologies you are using.
    > JSP only generates a markup document from the HTTP request for the HTTP
    > response and provided that is an (X)HTML document you can set a breakpoint
    > within the `script' element in the response document with Firebug, without
    > having to edit that document.
    >
    > > Or maybe there's a way to see exactly in IE and FF what data is send
    > > by this form (it's using POST) and if it's different in any way.

    >
    > Either server-side (displaying the request variables via JSP) or in Firefox
    > with the LiveHTTPHeaders extension.  But that is not going to solve your
    > immediate problem.
    >
    > PointedEars
    > --
    > Anyone who slaps a 'this page is best viewed with Browser X' label on
    > a Web page appears to be yearning for the bad old days, before the Web,
    > when you had very little chance of reading a document written on another
    > computer, another word processor, or another network. -- Tim Berners-Lee


    Hi, thanks for help :)

    The app is not mine and I didn't write it. It uses tens of js
    deprecated/IE-only stuff like document.all, readyState, namedItem,
    parentElement, IE-only events, IE-only way of inserting and creating
    elements, firstChild that in FF gets a text node instead of element
    node, billions of global variables, getElementById when element has no
    id, but name only, misuses eval(), links and so on. The js code in .js
    files only has about 500kb and there's js code in .jsp files as well.

    I tried to debug it in FF and correct the code, but reached a dead
    point where I can step through the whole code in IE and FF without any
    errors and all variables have the same values in both browsers, but FF
    simply hangs after submitting the form.

    I'm using FF because it's standard compliant (i.e. Opera implements
    many IE-only methods and properties), has Firebug and works on Linux.
    Right now the app being IE-only can be used only on Windows (it
    doesn't work on Linux+Wine+IE).

    I've created another topic about it: "Strange problem with
    form.submit() on FF and stack overflow ". There's not much info as
    well, but the problem is really strange - at least for me.
    szimek, Feb 15, 2008
    #3
  4. szimek wrote:

    > I've got very sick IE-only app


    Pleonasm :)

    > and I'm trying to make it FF compatible.


    Not the most easy task.

    > Here's one of maaany problems.
    > There's a link (it's actually a span element with onclick event
    > handler) that triggers javascript function that submits a hidden form.
    > This form action attribute is set to "main.jsp".


    So far, this sounds like a reasonable design.

    > In IE after clicking this button, the onclick event is later passed to
    > the body element, but there's nothing interesting going on.


    Sounds strange. You say that the form is submitted at that onClick-
    event, so one shouldn't rely on code that comes after it anymore,
    because a new HTTP request is done already.

    > In the main.jsp file there's "parent.document.location=logout_page.jsp"
    > js code that redirects it to the logout page.


    That is possible, but it's perhaps better to just let 'main.jsp'
    output the HTML-code of 'logout_page.jsp'.

    > In FF the event is also passed to the body element, but the whole apge
    > just halts with the wait cursor. I've put the "debugger" keyword right
    > before the js code mentioned before (document.location) and the IE
    > debugger halts on it, but the Firebug doesn't see it and the page just
    > hangs.
    >
    > It works fine in Opera 9.23...


    I'm having difficulties to understand what you mean here.

    > I have no idea how the main.jsp is generated, but is there some way to
    > break on the first line of the generated main.jsp that the form action
    > points to? This way I could see if the generated FF version differs
    > from IE version. I really have no other idea how to solve this
    > problem.


    One common debug method is to put an alert()-command at the spot in
    question, and to comment out the rest of the code. This way you could
    check variables, outcomes from functions, etc. step-by-step and only
    proceeding to a next level if the former is error-free.

    > Or maybe there's a way to see exactly in IE and FF what data is send
    > by this form (it's using POST) and if it's different in any way.


    'main.jsp' receives the POST-ed data. One debug method is to let
    'main.jsp' output the received data to screen and exit the program.

    Hope this helps,

    --
    Bart
    Bart Van der Donck, Feb 15, 2008
    #4
  5. szimek

    szimek Guest

    On 15 Lut, 10:55, Bart Van der Donck <> wrote:
    > szimek wrote:
    > > I've got very sick IE-only app

    >
    > Pleonasm :)
    >
    > > and I'm trying to make it FF compatible.

    >
    > Not the most easy task.
    >
    > > Here's one of maaany problems.
    > > There's a link (it's actually a span element with onclick event
    > > handler) that triggers javascript function that submits a hidden form.
    > > This form action attribute is set to "main.jsp".

    >
    > So far, this sounds like a reasonable design.
    >
    > > In IE after clicking this button, the onclick event is later passed to
    > > the body element, but there's nothing interesting going on.

    >
    > Sounds strange. You say that the form is submitted at that onClick-
    > event, so one shouldn't rely on code that comes after it anymore,
    > because a new HTTP request is done already.
    >
    > > In the main.jsp file there's "parent.document.location=logout_page.jsp"
    > > js code that redirects it to the logout page.

    >
    > That is possible, but it's perhaps better to just let 'main.jsp'
    > output the HTML-code of 'logout_page.jsp'.
    >
    > > In FF the event is also passed to the body element, but the whole apge
    > > just halts with the wait cursor. I've put the "debugger" keyword right
    > > before the js code mentioned before (document.location) and the IE
    > > debugger halts on it, but the Firebug doesn't see it and the page just
    > > hangs.

    >
    > > It works fine in Opera 9.23...

    >
    > I'm having difficulties to understand what you mean here.
    >
    > > I have no idea how the main.jsp is generated, but is there some way to
    > > break on the first line of the generated main.jsp that the form action
    > > points to? This way I could see if the generated FF version differs
    > > from IE version. I really have no other idea how to solve this
    > > problem.

    >
    > One common debug method is to put an alert()-command at the spot in
    > question, and to comment out the rest of the code. This way you could
    > check variables, outcomes from functions, etc. step-by-step and only
    > proceeding to a next level if the former is error-free.
    >
    > > Or maybe there's a way to see exactly in IE and FF what data is send
    > > by this form (it's using POST) and if it's different in any way.

    >
    > 'main.jsp' receives the POST-ed data. One debug method is to let
    > 'main.jsp' output the received data to screen and exit the program.
    >
    > Hope this helps,
    >
    > --
    >  Bart


    Thanks! I solved the problem using Firefox 3 beta, which sends POST
    request on form.submit() :) No idea why it doesn't work in FF 2.
    szimek, Feb 15, 2008
    #5
  6. szimek wrote:

    > On 15 Lut, 10:55, Bart Van der Donck wrote:
    >> [...]

    > Thanks! I solved the problem using Firefox 3 beta, which sends POST
    > request on form.submit() :) No idea why it doesn't work in FF 2.


    When FF3 uses the POST-method, it should be the same under FF2. Any
    javascript function that submits a form, does so in the method that is
    specified by the form's 'method'-argument. In other words, <form
    method="post" action="main.jsp"> is for POST and <form method="get"
    action="main.jsp"> for GET. In absence of this argument (like <form
    action="main.jsp">), it defaults to GET.

    --
    Bart
    Bart Van der Donck, Feb 15, 2008
    #6
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark
    Replies:
    1
    Views:
    1,689
  2. Ghafran Abbas
    Replies:
    0
    Views:
    4,207
    Ghafran Abbas
    Oct 12, 2004
  3. The Crow
    Replies:
    2
    Views:
    4,372
    Bruce Barker
    Sep 27, 2005
  4. Paul Oakfleet
    Replies:
    1
    Views:
    847
    Chris Riesbeck
    Sep 10, 2003
  5. Joop
    Replies:
    5
    Views:
    586
Loading...

Share This Page