Closed Bug 40213 Opened 24 years ago Closed 24 years ago

can not submit form with javascript method submit().

Categories

(Core :: DOM: Core & HTML, defect, P1)

Product:
Core
Component:
DOM: Core & HTML
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: desale, Assigned: ruslan)

References

(
URL
)

Details

(Whiteboard: [dogfood+] [nsbeta2+])

Submitting form with input "submit" is fine, and is no problem. But if we try to use input "button" as a submit button, and if we try to call "submit()" method on click of that button, then it does not work. [It does not submit form.] So submit() method is broken. STEPS TO REPRODUCE: 1] Visit above specified URL. [I created testcase, and it is there] 2] You'll see two buttons. One is "input submit" button, and one is "input button". 3] Select any option is select, and then click "Submit button". [This time form gets submitted." 4] Load above specified URL again. 5] This time click "Normal Button" [Which calls "submit()" method] [This time form does not get submitted.] EXPECTED RESULTS: Form should get submitted with click of both buttons. ACTUAL RESULTS: Form gets submitted only with regular submit button, and not with normal button which uses "submit()" method. This is happening only on Linux. There are lots of sites use this kind of submit, using "submit()" methods on any events. Its a blocker to our automation on Linux.
Marking nsbeta2.
Keywords: nsbeta2
Priority: P3 → P1
Desale, please attach the testcase to this bug or make it available from outside the Netscape firewall. Thank you!
Sorry Johnny, I didn't thought of that point. Actually this testcase is calling cgi script, so instead of attaching testcase, I'm pasting HTML as well as CGI code, so you could copy and create same envoirnment. attaching testcase won't work because it needs to call that cgi script. Here is TESTCASE. "subonlinux.html" HTML CODE START: <html> <head> <title>subonlinux.html</title> </head> <script> <!-- function SubForm(){ document.workform.submit(); } //--> </script> <body> <form name="workform" action="http://bubblegum/ngdriver/cgi-bin/foo1.cgi" method="post" > Text to Input<input type="text" name="temptext" value="TextValue" size="40"><br> Select Something Here<select name="tempsel" multiple> <option value="SelectValue1">Option1</option> <option value="SelectValue2">Option2</option> <option value="SelectValue3">Option3</option> </select><br> Normal Button to submit form using Javascript method submit(): <input type="button" name="button2" value="Normal Button" onclick="SubForm();"><br> Submit Button to submit form: <input type="submit" name="sub2" value="Submit Button"> </form> </body> </html> HTML CODE END: "foo1.cgi" CGI SCRIPT START: #!/usr/local/bin/perl require "cgi-lib.pl"; print "Content-type: text/html", "\n\n"; MAIN: { &ReadParse(*input); $textval = $input{'temptext'}; $selval = $input{'tempsel'}; print "<HTML>\n"; print "<HEAD>\n"; print "<TITLE>CGI Test</TITLE>\n"; print "</HEAD>\n"; print "<BODY>\n"; print "<H2> Text Value is: $textval</H2><br>\n"; print "<H2> Select Value is: $selval</H2><br>\n"; print "</BODY>\n"; print "</HTML>\n"; } exit(0); CGI SCRIPT END: I guess this helps Johnny.
dogfood.
Keywords: dogfood
Putting on [dogfood+] radar.
Whiteboard: [dogfood+]
This is needed for beta2; giving PDT approval.
Whiteboard: [dogfood+] → [dogfood+] [nsbeta2+]
Re-assigning to myself to reduce Johnny's nsbeta2+ load.
Assignee: jst → nisheeth
I just tried this with today's 9 am optimized build and could not reproduce the bug. Prashant, please re-test this and update this bug. Thanks. I saw another problem, though. When the form is submitted via javascript the security warning dialog box does not show up. I've filed bug 40633 against dougt to track this.
Status: NEW → ASSIGNED
Updating status whiteboard...
Whiteboard: [dogfood+] [nsbeta2+] → [dogfood+] [nsbeta2+] (Cannot reproduce in today's build)
Nisheeth, I just tested it with todays build [2000-05-25-08] on linux, and I can still see it happening. It is reproducible on my machine. Did you try on linux ? It is plat-form specific.
My bad. I tested this on Win32. I will continue to investigate this...
Whiteboard: [dogfood+] [nsbeta2+] (Cannot reproduce in today's build) → [dogfood+] [nsbeta2+]
*** Bug 39809 has been marked as a duplicate of this bug. ***
The following error gets reported to the console when the first form submit oberserver is notified of the javascript initiated form submit by nsFormFrame::OnSubmit: Opening file DistinguishedSchema.tbl failed Opening file FieldSchema.tbl failed Opening file URLFieldSchema.tbl failed Opening file SchemaConcat.tbl failed Opening file 57389324.s failed This is what gets printed to the console when the second form submit observer is notified. JavaScript error: http://bubblegum/desale/subonlinux.html line 9: The next step is to take a look at who these form submit observers are and what they are doing. Coming up just as soon as I figure out how to step my way through the com ptr code that lies between nsFormFrame and the form submit observer's Notify() method.
I just tried this on Linux and I am able to submit the form using both buttons. Can someone confirm that this is fixed?
Which Builds did you use Brian ?
I used my own build from this morning.
Amazing. Its not working for me.
Ok, so I see this problem on today's nightly build, but I do not see it on my debug build.
This is what we send to the server when posting the form at: http://blueviper/forms/subonlinux.html The post data is never sent, so the server never responds, and we never see the next page. POST /ngdriver/cgi-bin/foo1.cgi HTTP/1.1 Referer: http://blueviper/forms/subonlinux.html Cookie: USER_ID=208.12.37.57-3902392960.29329365; VER=3.51; PersonalLogin=name%3Aadmin%20key%3A%20remember%3Aundefined; Bugzilla_login=pollmann@netscape.com; Bugzilla_logincookie=42945; RoxenUserID=0xab922 Host: bubblegum:80 User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.12-20 i686; en-US; m16) Gecko/20000430 Accept: */* Accept-Language: en Accept-Encoding: gzip,deflate,compress,identity Keep-Alive: 300 Connection: keep-alive
Eric and I have looked at this in some depth and here's what we came up with. 1) When the "Normal button" button is clicked, only the headers pasted above by Eric are sent over the wire. The post data is never sent. 2) Then, when the "Submit button" button is clicked, the post data from the *previous* "Normal Button" initiated form submit gets sent across the wire. 3) Then, when we exit mozilla, the following message is printed on the console: "we have an event stuck -- removing it" and mozilla hangs. Hitting Ctrl-C exits the app and also submits the second "Submit Button" initiated form submit. 2) and 3) are provided for extra information. 1) is where we should concentrate are attention. Re-assigning to Gagan because 1) seems to be a necko problem.
Assignee: nisheeth → gagan
Status: ASSIGNED → NEW
ruslan: are we waiting for a continue for POST cases now? I didn't think so. Could you investigate this?
Assignee: gagan → ruslan
No. We don't wait for continue; but it doesn't matter since we're not asking for continue to be sent. I can look into it, but looks like an application-level problem, such as no input stream is provided most likely.
Status: NEW → ASSIGNED
I agree. It should not matter whether you click on the Submit button or use JS call to submit. They should be following the same path before getting to necko. nisheeth you want to own this back?
> such as no input stream is provided most likely This seems unlikely to me because of the behaviour Nisheeth described - the stream was eventually posted when the "Submit" button was clicked on. Maybe someone isn't closing the write to the server when they should or something? I don't know, but certainly the netlib layer gets the post data!
OK. Pav's fix for plevents didn't seem to help. It appears as when post is done from JS - the events are no longer being delieved and the entire product is hosed. Http handler never gets it's OnStopRequest event from the socket transport after submitting headers It didn't even show the security warning dialog which would normally appear with regular post. Looks like there's some JS Unix specific problem.
Ok. Cool. Pav had supplied a better fix which fixes event queues on unix and this bug as well.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
Marking verified. Verified with 2000-060108. Working perfect. Thnaks for fixing this. I really needed this one.
You need to log in before you can comment on or make changes to this bug.