We have a popup window that has a submit element and a button. On clicking either button we would like the window to close. There does not seem to be a way to do this. Our html engineers have tried: 1. placing a <a href=".." onlclick=this.close()><input...></a> 2. using the onclick in <input ... onlick=this.close()> 3. using the onsubmit in the form element <form ... onsubmit=...> All of these work with Internet Explorer. and are part of the standard spec. I can conceive that there may be a problem with 1: which should be called first the "<a href" action or the input submission action. But the other two options are not problematic. This may be a duplicate of 67875. But I was not quite sure, as the xhtml references are missing. I will attach the two problem files. Henry

QA contact updated

I am not sure really what to do with this bug. Still a problem in the latest nightlies?

alright.... Here's the problem as I see it. When a button is clicked (a submit button for a form), I would expect any onclick event for the button to be processed first. Once the onclick event is processed, the window is gone, and what is there to submit? To get this to work in all browsers, I would suggest having an onclick event handler that first calls the form's submit() method and only after that calls window.close()... All that said, over to DOM events for investigation. Should we be processing the submit() at all here? If the window.close() returns success?

-> moz 1.1, 4.x and IE compatibility issue

this problem is deeper than simply closing windows: onsubmit and/or onclick allows one to verify form inputs before the form is actually submitted. this seriously breaks forms with required fields - mozilla submits the form with blank entires, while IE/others present the user with a warning. Example code below: function validate() { if (formthing.elementname.value == "") { alert("You must enter somthing."); event.returnValue=false; formthing.elementname.focus(); } } <FORM ACTION="file.php" NAME="formthing" METHOD="post" onsubmit="validate();"> <INPUT TYPE="Text" name="elementname"> <INPUT TYPE="Submit" value="Submit"> </FORM>

Comment 8 has buggy code... "event.returnValue=false;" is an IE-ism. The global event object is something IE sort of made up. If your "validate" function took an argument and your handler definition passed it an event like so: onsubmit="validate(event);" then you could call event.preventDefault() in the handler to prevent the efault action (this is the correct way per the DOM Events module). Or your handler should return "false" for cases when you want to prevent the action.

These test cases work with a 2002-02-06-03/win2k build and a very old 2001-11-10-06/Linux build. I am getting a newer Linux build, but this looks like a works for me. Anyone disagree?

looks like this works in Linux 2002 02 08 07 trunk build as well. Can we mark this wfm and get it off the radar?

This attachment opens a new window, submits the form with the target set to the new window and closes the opener window. On netscape 6.2 and mozilla 0.9.7 (win95/98/linux) the new window is opened but the submit action doesn't take place. On IE it works.

jkeiser, could you test that last testcase with the new form submission code? I can reproduce the problem in Roger's testcase. I get the alert asking me whether I'm sure I want to submit insecurely and then the window closes and no submission happens. Note that putting the close() call on a timeout ("setTimeout(self.close, 0)") will make the form submit....

bz, i see what you mean, but can we clean this bug up so the summary means something? Change "onsubmit in form element does not work, neither does onclick help" to "race between form submit and window.close" perhaps? Also, the last test case is reproducible in Win2k with or without using a password field, so I recommend OS -> ALL.

-> form submission

Dup of bug 93694?

*** Bug 93694 has been marked as a duplicate of this bug. ***

*** Bug 187554 has been marked as a duplicate of this bug. ***

*** Bug 356553 has been marked as a duplicate of this bug. ***

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information