Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Problem with submit in IE and FF

Reply
Thread Tools

Problem with submit in IE and FF

 
 
szimek
Guest
Posts: n/a
 
      02-11-2008
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
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      02-15-2008
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_not...ml#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
 
Reply With Quote
 
 
 
 
szimek
Guest
Posts: n/a
 
      02-15-2008
On 15 Lut, 01:23, Thomas 'PointedEars' Lahn <(E-Mail Removed)>
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_not...ml#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.
 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      02-15-2008
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
 
Reply With Quote
 
szimek
Guest
Posts: n/a
 
      02-15-2008
On 15 Lut, 10:55, Bart Van der Donck <(E-Mail Removed)> 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.
 
Reply With Quote
 
Bart Van der Donck
Guest
Posts: n/a
 
      02-15-2008
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
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Catching Submit Event even called by document.forms[0].submit() The Crow ASP .Net 2 09-27-2005 05:03 PM
javascript submit problem : form won't submit Joop Javascript 5 03-23-2005 07:48 PM
Preventing Multiple submit (Disabling Submit Button Post Click) Solution Mark ASP .Net 1 12-13-2004 08:03 PM
Disable Submit Button on Post back and On Submit in ASP.net Ghafran Abbas ASP .Net 0 10-12-2004 06:11 PM
Disable Submit Button until Accept Terms and Redirect Page on Submit Paul Oakfleet Javascript 1 09-10-2003 06:07 PM



Advertisments