Problem with submit in IE and FF

[szimek]

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

 

[Thomas 'PointedEars' Lahn]

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

 

[szimek]

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.

 

[Bart Van der Donck]

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,

 

[szimek]

Pleonasm


Not the most easy task.


So far, this sounds like a reasonable design.


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.


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



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


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.


'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,

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.

 

[Bart Van der Donck]

[...]

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.