Submit name/value pairs for submit buttons that triggered javascript submission

VERIFIED FIXED in mozilla1.2beta



17 years ago
3 months ago


(Reporter: palmerc, Assigned: alexsavulov)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)



(8 attachments, 17 obsolete attachments)

22.42 KB, text/html
25.43 KB, text/html
26.00 KB, text/html
21.95 KB, text/html
2.58 KB, text/html
2.54 KB, text/html
42.19 KB, patch
: review+
: superreview+
Details | Diff | Splinter Review
2.92 KB, text/html


17 years ago
Mozilla 1.0 Release Candidate 1 - Completed April 18, 2002:
Installed in NT4, SP6 environment
When I was trying to apply for a job from the site (unfortunately
only available to registered users thereon), selecting the APPLY NOW button on
the "Enter Cover Letter" page, consistently took me to the "Preview Cover
Letter" page - which was the button to the left of "APPLY NOW".  Was unable to
make it work correctly, even after uninstalling and re-installing Moz 1.0rc1. 
Mozilla 0.9.9, NS 4.79, and MS IE 4.0 worked fine!

Attempted to view the source of the Preview and apply now button areas, but
could not do so.

This error forced me to retrun to Mozilla 0.9.9.

I've copied the source from a different visit to the same page:

<title>CareerBuilder (Apply Online)</title>

<script language=JavaScript>
if (parent.frames.length > 0)
					{parent.location.href = location.href;}
<script language="JavaScript">
//ideally this will be run on only a few servers in a server farm to give it a
random not every user feel. This will also
			//increase the duration of the poll to get a better agragate.

			//For setting client variable
			function setCookie(name, value) 
				var expires = "Friday, 01-May-2002 09:00:00 GMT";
				var curCookie = name + "=" + escape(value) + "; expires=" + expires + "; path=/";
				document.cookie = curCookie;

			//For getting client variable
			function getCookie(name) 
				var prefix = name + "=";
				var cookieStartIndex = document.cookie.indexOf(prefix);
				if (cookieStartIndex == -1)
					return null;
				var cookieEndIndex = document.cookie.indexOf(";", cookieStartIndex + prefix.length);
				if (cookieEndIndex == -1)
					cookieEndIndex = document.cookie.length;
				return unescape(document.cookie.substring(cookieStartIndex + prefix.length,
			//For for running survey
			function WhatsNewWindow(surveyIndex)
				if (!getCookie('runSurveyOnce'))
					survey =,'survey','width=500,height=600,scrollbars=yes,resizable=no,toolbar=no');
					setCookie('runSurveyOnce', 'ThankYou');
			</script> <!-- Diff=1 -->


<body bgcolor=white text=black link="#214a5a" vlink="#ff6600" alink="#ff9900"
topmargin=0 leftmargin=0 marginheight=0 marginwidth=0>
<script language=JavaScript><!--
var sBrowserName, sBrowserVersion
var bShowRollovers
sBrowserName = navigator.appName;
sBrowserVersion = parseInt(navigator.appVersion);
bShowRollovers = false;
if (sBrowserName == "Netscape" && sBrowserVersion >= 3)
	bShowRollovers = true;
else if(sBrowserName == "Microsoft Internet Explorer" && sBrowserVersion >=4)
	bShowRollovers = true;

function preloadImages() {
	if (document.images && bShowRollovers) {
		var imgFiles = preloadImages.arguments;
		var preloadArray = new Array();
		for (var i=0; i<imgFiles.length; i++) 
			preloadArray[i] = new Image;
			preloadArray[i].src = imgFiles[i];
function imgMouseOver(imgName) { if (bShowRollovers==true)
document.images[imgName].src = eval(imgName + "_On.src"); }
function imgMouseOut(imgName)  { if (bShowRollovers==true)
document.images[imgName].src = eval(imgName + '_Off.src'); }

<script language="JavaScript">
function MM_preloadImages() { //v3.0
  var d=document; if(d.images){ if(!d.MM_p) d.MM_p=new Array();
    var i,j=d.MM_p.length,a=MM_preloadImages.arguments; for(i=0; i<a.length; i++)
    if (a[i].indexOf("#")!=0){ d.MM_p[j]=new Image; d.MM_p[j++].src=a[i];}}

function MM_swapImgRestore() { //v3.0
  var i,x,a=document.MM_sr; for(i=0;a&&i<a.length&&(x=a[i])&&x.oSrc;i++)

function MM_findObj(n, d) { //v4.0
  var p,i,x;  if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) {
    d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);}
  if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++)
  for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document);
  if(!x && document.getElementById) x=document.getElementById(n); return x;

function MM_swapImage() { //v3.0
  var i,j=0,x,a=MM_swapImage.arguments; document.MM_sr=new Array;
   if ((x=MM_findObj(a[i]))!=null){document.MM_sr[j++]=x; if(!x.oSrc)
x.oSrc=x.src; x.src=a[i+2];}

<script language=JavaScript><!--
			if (bShowRollovers==true) {
				TopMenu1_On = new Image(19,19);
				TopMenu1_On.src =
				TopMenu1_Off = new Image(19,19);
				TopMenu1_Off.src =
				TopMenu2_On = new Image(19,19);
				TopMenu2_On.src =
				TopMenu2_Off = new Image(19,19);
				TopMenu2_Off.src =
				TopMenu3_On = new Image(19,19);
				TopMenu3_On.src =
				TopMenu3_Off = new Image(19,19);
				TopMenu3_Off.src =
				TopMenu4_On = new Image(19,19);
				TopMenu4_On.src =
				TopMenu4_Off = new Image(19,19);
				TopMenu4_Off.src =

<table cellspacing=0 cellpadding=0 width="100%" border=0>

<tr> <td bgcolor=#003399 height=9><img height=1
width=1 vspace=4 border=0></td>
<tr> <td bgcolor=#b8a0ae height=1><img height=1
width=1 border=0></td>
<tr> <td bgcolor=#715156 height=1><img height=1
width=1 border=0></td>
<tr> <td height=3><img height=1
width=1 vspace=1 border=0></td>

<table width="100%" border="0" cellspacing="0" cellpadding="0" height="70">
<tr> <td width="217" valign="bottom"><a href="/JobSeeker/Index.htm?ch=al"><img
width="217" height="50" border="0"></a></td>
<td width="100%" height=60 align="right"
width="468" height=60><iframe
frameborder=0 width=468 height=60 name=ad marginheight=0 marginwidth=0
scrolling=no noresize><a
target="_top"><img width=468 height=60 border=0
<table width="100%" border="0" cellspacing="0" cellpadding="0" height="23">

<td width="467"
valign="top"> <table width="572" border="0" cellspacing="0" cellpadding="0"
<td><font face="Arial, Helvetica"><img
width="13" height="1"><font size="2"><font size=2
face="arial,helvetica">&nbsp;&nbsp;&nbsp;You are currently logged in
as&nbsp;&nbsp;&nbsp;<b></b>.&nbsp; <font face="arial,helvetica"
size=1>(<a href="/share/Logout.asp?ch=al"

width="15" height="23"></td>
<td width="83"><img
width="83" height="23"></td>
<table width="100%" border="0" cellspacing="0" cellpadding="0">

<table width="400" border="0" cellspacing="0" cellpadding="0">
<tr><td align="center" width="400"><nobr><font face="Arial, Helvetica"
width="13" height="1"></font><a href="/JobSeeker/Index.htm?ch=al"><img
width="81" height="26" border="0" alt="Find Jobs? Click here!"><a
width="120" height="26" border="0" alt="Post Resumes? Click here!"><a
width="130" height="26" border="0"></a><a href="/JobSeeker/Index.htm?ch=al"><img
width="69" height="26" border="0" alt="Home? Click here!"></nobr></td></tr>
<td align="center" width="400"><img
width="208" height="26"></td>
<td width="130"><a href="/JobPoster/Index.htm?ch=al"><img
width="130" height="26" alt="Employer? Click here!" border=0></a>
<table width="100%" border="0" cellspacing="0" cellpadding="0">

<td width="6"><img
width="6" height="1"></td>
<td width="130"><img
width="150" height="17"></td>
<td width="210"><img
width="220" height="17"></td>
<td width="100%"><img
width="2" height="2"></td>
<font face="arial,helvetica" size=1><font
face="verdana,arial,helvetica"><b>Location: </b></font>Apply Online</font><br>

<table width="100%" cellpadding=0 cellspacing=0 border=0>
<tr><td width=13><img
width=1 hspace=6 height=1></td>
<td width="100%">
<!-- NetFo(TS=04/21/2002 8:31:59 AM; LMN=WASABI1; -->

<script language=javascript><!--
				function buttonsubmit_onclick() {
					// this function clears the "form incomplete" flag and submits the form

					if (document.frmAO.didsubmit.value == '0') {
						document.frmAO.action =
					else {
						return false
method=post name=frmAO>

<input type=hidden name=didsubmit value='0'>
<input type=hidden name="cl" value="">
<table border=0 width=600>
<table border=0  bgcolor="#9cbaed" cellspacing=0 cellpadding=3><tr><td>
<table border=0
cellspacing=0 cellpadding=0>
<tr><td colspan=3>
<font face="arial,helvetica" size=2><b>Congratulations!&nbsp;&nbsp;&nbsp;You're
taking an important step toward a new career.

<tr><td valign=top>
<table border=0>
<tr><td valign=top colspan=2><font face="arial,helvetica" size=4><b>Step
1.&nbsp;&nbsp;Confirm Job</b></td></tr>
<tr><td><font face="arial,helvetica" size=2><b>I'm applying for:</b></td></tr>

<tr><td align=right nowrap><font face="arial,helvetica" size=2><b>Job
<td><font face="arial,helvetica" size=2>QA Engineer (Batch Process Control
<tr><td align=right nowrap><font face="arial,helvetica"
<td><font face="arial,helvetica" size=2>US-AZ-Phoenix</font></td>
<tr><td align=right nowrap><font face="arial,helvetica"

<td><font face="arial,helvetica" size=2>Rockwell Automation</font></td>
<td width=20>&nbsp;</td>
<td valign=top>
<table border=0>
<tr><td valign=top><font face="arial,helvetica" size=4><b>Step
2.&nbsp;&nbsp;Select Resume</b></td></tr>

<tr><td>&nbsp;&nbsp;&nbsp;<font face="arial,helvetica" size=1>Click a resume to
view it</font></td></tr>
<td colspan=2 valign=top nowrap>
<font face="arial,helvetica" size=2><input type=radio
onchange=document.frmAO.didsubmit.value='0' name=rdidandtitle
value="R048F78YSWWTFYZXXR,Engineering" checked>&nbsp;&nbsp;<a
face="arial,helvetica" size=2><input type=radio
onchange=document.frmAO.didsubmit.value='0' name=rdidandtitle
face="arial,helvetica" size=2><input type=radio
onchange=document.frmAO.didsubmit.value='0' name=rdidandtitle
value="RA7F61MKTZV0SYGH2J,Sr. Technical/Lead Tech/Manager">&nbsp;&nbsp;<a
Technical/Lead Tech/Manager</a><br>

<tr><td colspan=3>
<a name=continue>
<font face="arial,helvetica" size=4><b>Step 3.&nbsp;&nbsp;Enter Cover

<table border=0 width=500><tr><td>
<font size=2 face="arial,helvetica">
This is your opportunity to make a good first impression on a 
											potential employer. A cover letter is often helpful.


<table border=0 cellpadding=0 cellspacing=0>
<td valign=top>
<font face="arial,helvetica" size=2><b>Choose a cover
letter:</b></font><br><font face="arial,helvetica" size=1>(You will have a
chance to modify it before it is
sent.)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</font><font face="arial,helvetica"
size=2><br><input id=1 type=radio name=cl value="CLA7F61MKTZV1KMXGTL"><label
For=1 onmouseover="'blue'"
onmouseout="'black'">Cover Letter</label><br><input id=2
type=radio name=cl value="CL05T96HK5V1K9P9FCW"><label For=2
onmouseout="'black'">MyCoverLetter 1</label></td><td
valign=top><font face="arial,helvetica" size=2><b>Or:</b>

<font face="arial,helvetica" size=2><br>
<input type=radio id=none name=cl value="none" checked><label For=none
onmouseover="'blue'" onmouseout="'black'">No
cover letter</label><br>
<input type=radio id=new name=cl value="new"><label For=new
onmouseout="'black'">Create a new cover letter now</label><br>
<center><input type=image
 alt="Continue" width=175 height=31 border=0 id=image1 name=image1></center>

<input type=hidden name=jdid value="JY6TQ6PHM5FYPH5FWC">
<input type=hidden name=udid value="UB6MJ1MKTZVPJ8QJPP">
</td><td width=13><img
width=1 hspace=6 height=1></td>

<br clear=all>
<center><font size=2 face="arial,helvetica">
<a href="/JobSeeker/Help/Feedback.asp?ch=al">Feedback</a> &nbsp;&#149;&nbsp;
<a href="/JobSeeker/Help/Index.htm?ch=al">Help</a> &nbsp;&#149;&nbsp;
<!--<a href="/JobSeeker/SiteMap.htm?ch=al">Site Map</a> &nbsp;&#149;&nbsp;-->
<a href="/JobSeeker/AboutUs/Index.htm?ch=al">About Us</a> &nbsp;&#149;&nbsp;

<a href="/JobSeeker/Info/Privacy.htm?ch=al">Privacy</a>
<p><font size=1>CareerBuilder Customer Service: 800-891-8880 8 am - 8 pm ET, M -

I don't see an "Apply Now" button on this page.

Comment 3

17 years ago
Select "Continue" after selecting a cover letter.  The succeeding page has
"Proview" and "Apply Now" buttons below the edit window containing the cover
letter text.  Selecting the "Apply Now" button should submit the application,
but in 1.0rc1, actually selects the "preview" page, as does selection of the
"preview" button.  In 0.9.9, NS 4.79, and IE, the page works properly.
Cliff: can you do a File: Save Page As...Web Page, HTML Only on the page that
actually has the Apply Now button and attach it to this bug using the "Create a
New Attachment" link?  My guess is that there's bad markup on that page and our
algorithm for error recovery changed, but I need to see the source in question.

Comment 5

17 years ago
Attached file captured using "Save Page as" from the affected page, under
Mozilla 0.9.9.

I hope this is was you wanted.	I can, if requested capture the same
from 1.0rc1.

Comment 6

17 years ago
The problem persists in Mozilla 1.0 Release Candidate 2
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc2) Gecko/20020510.  When I
click on the "Apply Now" button, it takes me to the URL for the Preview button.

Comment 7

17 years ago
Problem continues in Mozilla 1.0 Release Candidate 3
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020523.

Behavior identical to 1.0RC1 and 1.0RC2.  Problem does NOT exist in 0.9.9.
Keywords: qawanted

Comment 8

17 years ago
Problem persists in Mozilla 1.0
(Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530) under NT4, SP6.

Comment 9

17 years ago
I can confirm this problem in build 2002071608 PC/Win98.

Going to try and pare the code down into a testcase.
Ever confirmed: true

Comment 10

17 years ago
Posted file Minimal testcase (obsolete) —
I don't see from it what the problem is, but I do have a pared-down minimum

The only problem is that to have the testcase work, an INPUT tag that
identifies the resume to be submitted to the job has to be present.  Since I
have a resume on the HeadHunter system (now called Careerbuilder after a
merger), I can use the testcase locally.  But I am not really willing to have
my live resume used in a public testcase here.	I'm posting the testcase with
the INPUT tag deliberately broken, with comments in the HTML code on how to
have it work for anyone who is going to work on this bug (basically meaning you
have to have your own Careerbuilder account, post a resume, and have the INPUT
tag point to it).

Comment 11

17 years ago
Added keyword testcase.
Keywords: qawantedtestcase

Comment 12

17 years ago
I will gladly volunteer to test any build that contains a fix for this bug.  If
someone will kindly let me know via email when a build is created that contains
a fix, I will test the fix using my Careerbuilder account.  Please advise at
email address ''.  Thanks!

Cliff palmer
-> Form submission
Assignee: Matti → alexsavulov
Component: Browser-General → Form Submission
QA Contact: imajes-qa → vladimire

Comment 14

17 years ago
also, i don't see here a form submission problem but rather a problem occuring
be cause of the cache-cotrol: private flag set by the server in it's response
and the window.history.go(1) javascript directive. so in case that the user does
not change the content of the textarea, the history.go(1) sends the user forward
in the history. if the user clicked on "preview" before, then he went back and
then he clicks "apply now" without having changed anything, well he should get
again the result of the preview, but since the server sends "cache-cotrol:
private" with every answer, the page is not in the cache. then this annoyiong
"confirmation" dialog (the damn POSTDATA thing) appears and asks the user if ok
to send. now maybe we handle the "cache-control: private" wrong:

private = [field-name] Indicates that the object (or specified field) must not
be stored in a shared cache

now many will interpret this as "do not store at all", but i saw also statements
that say a user's cache is allowed to store the data.

over to history. pass it back if you think that is form sub.

(tested with the flag turned off and there is no formsubmission problem)
Assignee: alexsavulov → radha
Component: Form Submission → History: Session
QA Contact: vladimire → claudius

Comment 15

17 years ago
remove `testcase' from keywords field. The minimal testcase is wrong:
  <input type="hidden" name="didsubmit" value="1">
should be
  <input type="hidden" name="didsubmit" value="0">

I cannot reproduce any problem with the captured source code. Perhaps
because the base url is not specified and I'm running the test case
on Bugzilla server & local host. Reporter, can you please provide
the url where this problem occurs? Also, please describe the problem.
"does not work correctly" is not a good description.

Anyway, this is indeed not a form submission bug.
Keywords: testcase

Comment 16

17 years ago
Posted file Testcase (obsolete) —
Testcase with INPUT tag corrected, FORM action updated to point to a current
Careerbuilder job listing since the previous one was no longer on the system.
Attachment #92107 - Attachment is obsolete: true

Comment 17

17 years ago
Re: comment 15
You cannot offer a specific URL to point to because you have to be logged into
the Careerbuilder system in the first place.

The problem is already exactly described in the description:
"When I was trying to apply for a job from the site (unfortunately
only available to registered users thereon), selecting the APPLY NOW button on
the "Enter Cover Letter" page, consistently took me to the "Preview Cover
Letter" page - which was the button to the left of "APPLY NOW"."

This problem still exists in build 2002092604.

Re: comment 14
But if I can (and I can) reproduce this problem by going directly to the form
for the first time in my session, and click only on APPLY NOW and get the wrong
result, I do not see how this is a History problem.  I've arrived at the form
for the first time, clicked on APPLY NOW, and instead gotten the result of
PREVIEW COVER LETTER.  There is no session history at work there since I'm here
for the first time in this browsing session.

Readded kw testcase
Keywords: testcase

Comment 18

17 years ago
Posted file new testcase (obsolete) —
testcase based on attachment 80291 [details]. On MSIE 5/win, the form always goes
to a preview page. *sigh*, I guess it's not possible hacking around
CareerBuilder offline...


17 years ago
Keywords: qawanted

Comment 19

17 years ago
URL from which this problem was encountered (again today with Moz 1.1/Win NT)

Another copy of the problem page source text is attached.

I know this problem is very hard to test, since it is deep within the
Careerbuilder website, requires an account there, and is encountered only when
the job postings are using the Careerbuilder "job application" facilities
(instead of being redirected to the employer's website), but the problem DOES
NOT OCCUR when the Careerbuilder website is visited through Mozilla 0.9.9,
Netscape 4.79, or IE 6.

It is probably something in the Careerbuilder site's encoding, but the problem
makes it impossible to apply through Mozilla.

Your continued patience with researching and resolving this bug is sincerely


Cliff Palmer

Comment 20

17 years ago
update relative url to make it work. Confirmed MSIE5 will submit this
page correctly, Mozilla won't
Attachment #101834 - Attachment is obsolete: true
Attachment #101837 - Attachment is obsolete: true

Comment 21

17 years ago
phew... finally found what's wrong with it:

if (document.frmAO.didsubmit.value == '0') {
  // document.frmAO.submit()

if you comment out the line "document.frmAO.submit()" (browser
will still submit the form after exiting the function) OR
if you move the line outside the IF block, the form will submit
correctly. It seems that frmAO.didsubmit was not fully updated until
exiting the IF block

Comment 22

17 years ago
I can't find a dupe of this. Reporter, you might want to file a
separate Tech Evangelism bug to get CareerBuilder to fix this bug.

/and apology to Volt for all the garbage I sent them/
Keywords: qawanted
Summary: Incorrect Link Resolution from Embedded Button Links → Input values not updated if value change and form.submit() are in the same IF block

Comment 23

17 years ago
Your testcase does not work for me in build 2002100508 PC/Win98.

Comment 24

17 years ago
sorry, my mistake. Looks like you have to comment out all the
submit() statement in the javascript for form submission to work
Assignee: radha → alexsavulov
Component: History: Session → Form Submission
QA Contact: claudius → vladimire
Summary: Input values not updated if value change and form.submit() are in the same IF block → javascript input value change not taking effect on submit


17 years ago
Attachment #101515 - Attachment is obsolete: true

Comment 25

17 years ago
I spent some time investigating this issue, and it turns out that the problem is
caused by us not submitting name/value pair for the submit button (in this case
x/y coordinates of the image) tha caused the submission. IE and Netscape 4.x do
this, so we should probably do this as well for compatibility.
Keywords: 4xp
Priority: -- → P3
Summary: javascript input value change not taking effect on submit → Submit name/value pairs for submit buttons that triggered javascript submission

Comment 26

17 years ago
ok, i guess we should implement code that remembers the clicked form element
that caused the submission and when the name/value pairs are collected from the
form elements, process the triggering submit element too. let's see if we can do
that easily.
Target Milestone: --- → mozilla1.2beta

Comment 27

17 years ago
*** Bug 169935 has been marked as a duplicate of this bug. ***

Comment 28

17 years ago
OS=>All from Bug 169935
OS: Windows NT → All

Comment 29

17 years ago
*** Bug 170584 has been marked as a duplicate of this bug. ***

Comment 30

17 years ago
*** Bug 170881 has been marked as a duplicate of this bug. ***


17 years ago

Comment 32

17 years ago
yeah, is still making us look bad if more and more web developers are testing
their submission only with IE. do we want to live with that?
As you fix this, don't break IE compat in the case when the onsubmit/onclick
handler returns false... (right now IE and we behave identically in that case).

Comment 34

17 years ago
yeah, i spoke also with jkeiser about that. i'll see what can be done. i won't
apply any patch if it breaks anything we have so far.

Comment 35

17 years ago
Ok, here is what we have:

IE never submits the name/value pair. (we won't imitate this)
IE does not submit x/y if the onclick handler returns false. (compatible with us)
IE submits x/y if if the onclick handler returns true or nothng (we need a fix)

The issue about submiting the name/value everytime we submit x/y is to be discussed.

Comment 36

17 years ago
ok, this cannot be implemented easily if we want to do what IE does. that
requires us to submit asynchronously from JS hadlers like onClick otherwise we
cannot know the return value of the JS handler. IE submits asynchronously. I
think that is why IE never had problems with the double submission. is be cause
IE is collecting all the submit requests and posts them on the event loop. at
the end there is only one processing of the form and the events (if there are
more, they get removed). Proof:

function do_submit(frm, retval) {
  frm.inp2.value = "some other text";
  frm.inp2.value = "modified";
  return retval;
<form name="frm2" action="" method=post>
<input name="inp2" value="some text"><br>
<input type="image" name="img2" value="some_img2" src="test.gif" 
       onclick="frm2.submit();return do_submit(frm2, true)">

if the image is clicked, the received value for "inp2" will be "modified" if
this is posted with IE.

right now we submit syncronously on frame.submit(). that means that there is no
way for us to know what the return value of the handler was. also when JS is
invoking HTMLFormElement::Submit we don't know what was the originator of the
event. the HTMLInputElement get's notified about the click first after the
onClick handler was processed. if we don't inverse this order we can also not
know the originator.

all this requires some work if we want to act like IE. maybe de-synchronizing
the  form submission would be a good idea. that way we could also get rid of
this mIsSubmitting since there will be only one submission that will process all
the submission events from the queue. have to look into this. i will try to do
an experimental patch to achieve this. see how things are working then. there is
also bug 161990 that requests the improvment of the double submission prevention
so i think this is worth a try.

Comment 37

17 years ago
hmmm, there is a way to get the originator information before the submission is
started in nsGenericElement::HandleDOMEvent. still there is the problem with the
JS return value that cannot be known.

Comment 38

17 years ago
*** Bug 147093 has been marked as a duplicate of this bug. ***

Comment 39

17 years ago
*** Bug 169508 has been marked as a duplicate of this bug. ***

Comment 41

17 years ago

Comment 42

17 years ago
need to handle action, target and method correctly and do a lot of testing

Comment 44

17 years ago
Posted patch proposed patch (obsolete) — Splinter Review
i will also attach a testcase that goes trough all possibilities and
demonstrates why the patch is made that way


17 years ago
Attachment #105037 - Attachment description: testcase for the proposed patch → testcase for the proposed patch (uses two target windows)

Comment 46

17 years ago
john, can you review the patch please?
<form action="'baz';"
<input type="submit" name="catch_me" value"Here you go">

How does this patch handle that?

(I still question the need to "solve" this problem, btw, but if we have a good
solution, sure.)

Also, how does that code handle an exception being thrown during the
onclick/onsubmit processing?  Does the form submit?

Comment 48

17 years ago
yeah, good points. i'm trying to be as accurate as possible, still i might have
missed some points. i'm going to check the ones asked in the previous comment


17 years ago
Attachment #104738 - Attachment is obsolete: true

Comment 49

17 years ago
Comment on attachment 105035 [details] [diff] [review]
proposed patch

need to handle the cases Boris mentioned, particularily the one when JS throws
an exception.
Attachment #105035 - Flags: needs-work+

Comment 50

17 years ago
well, i have to admit: the two cases in comment 47 are pretty difficult to handle.

1. javascript: scheme

i had to add something to the patch to not end up in an endless recursion. that
way i just do what we did before. to catch the value i will have to place a
submission event on the queue for the form so i can pick up the triggering input
(this issue could be postponed in a subsequent bug report though since IE does
not handle the issue correctly too.)

2. exception

my patch adds a regression in the following case:

function ex_sub(frm, retval) { = "_self";
  frm.submit(); = "window2";
  bogus.nonexistent = "raise exception";
  return retval;
<input type=submit name="theexcept" value="the exception" 
 onclick="return ex_sub(frm1, true)">

in this case the 1st submission will be dropped. actually the problem is that my
patch deferrs the 1st submission until JS returns, but since the handler will
look like it returned true, the 1st submission will be dropped and a second one
will be created and submitted to "window2".

to fix that i need to know if there was an exception during the execution of
javascript after the call nsGenericHTMLLeafFormElement::HandleDOMEvent returns in
nsHTMLInputElement::HandleDOMEvent. I stepped trough JS_interpret(...) and it
does not look to me that the exception is propagated to the underlaying callers.
maybe I'm wrong. if anyone knows how to check for a possible exception in
nsHTMLInputElement::HandleDOMEvent please add a comment on this bug. thx!

as a general conclusion i would say that the patch is still valuable (with the
addition to prevent the endless loop). if there is an exception, well, that is
up to some extent a web author's foult too. it would be nice to handle that too
but if there is no way i can check for an exception as i mentioned above, the
patch for this bug and the current behavior in case of an exception kinda
exclude each other.

Comment 51

17 years ago
this pathci the same like the previous, it just inlcudes an endless recurtion
prevention in a case like 


see previous comment for remaining issues.
Attachment #105035 - Attachment is obsolete: true
What is current behavior in the case of an exception?  Do we submit or not
submit?  What is IE's behavior in the case of an exception?  Does it submit or not?

Comment 53

17 years ago
in the exception case (comment 50 @ 2) IE submits to both targets. also the
unpatched version of Mozilla. the patched version will only submit to the target
set right before the exception was raised. but that is wrong since the
submission object was actually prepared for the first target.

in the "javascript:" case both IE, and us (unpatched and patched) cannot catch
the name/value of the submitter element.

i'm doing research for the exception case to see if i can check for a JS
exception when i'm in the content's handler code (maybe the pres context or
shell or some other instance receives soem information about that). i will debug
the JS_interpret function to see what is going on there. if you know of
something let me know please.
The reason I asked what IE does is because it's not at all clear what "correct"
behavior is in the exception case....

Comment 55

17 years ago
i spoke with jkeiser and we think we should stick to what we had before (and
also what IE is doing) that is:

- if there is an exception in the onclick handler the form will submit normally
(like there is no javascript at all). the return value is ignored, default is
- if there is an exception after a form.submit() the whole thing will be
handled like in the case where the JS returns true. (we did the same before and
is ok, also IE does that)

- if there is a target or action change in the javascript, we flush the pending
deferred submission immediately. that won't change anything to the way the
patch worked before this change (i should have done that in the first line).
that will also fix the following testcase:

function ex_sub(frm, retval) { = "_self";
  frm.submit(); = "window2";

  bogus.whatever = "exception raiser";

  return retval;

there is still the unsolved case mentioned in comment 50 @1. but since neither
IE nor us handled that correctly before, i will open a separate bug for that.
Attachment #105175 - Attachment is obsolete: true

Comment 56

17 years ago
I have a banking site that has a page with Yes/No/Cancel buttons. None of the
buttons work, I think because of this bug. Can someone confirm?


<INPUT TYPE=SUBMIT NAME="BUTTON" VALUE="  Yes  " OnClick="javascript:
<INPUT TYPE=SUBMIT name="BUTTON" VALUE="   No  " OnClick="javascript:

selfpost() looks like:
function selfpost() {
	document.feeaccount.action = 'feeaccount.asp';


Comment 57

17 years ago
Posted patch 4th improved patch (obsolete) — Splinter Review
John, I have to check again but right now I think I have to let
mSubmissionDeferrred in. Also I cannot move the deletion of the mSubmission to
ForgetCurentSubmission. All be cause of the change in
nsHTMLFormElement::SetAttr(). I know it sucks, but that's it.
Attachment #105292 - Attachment is obsolete: true


17 years ago
Attachment #105825 - Flags: review?(jkeiser)


17 years ago
Blocks: 161990
Comment on attachment 105825 [details] [diff] [review]
4th improved patch

>Index: html/content/public/nsIForm.h
>+  NS_IMETHOD OnSubmitButtonOrImageBegin() = 0;
>+  NS_IMETHOD OnSubmitButtonOrImageEnd() = 0;

A quick note, OnSubmitClickBegin() and OnSubmitClickEnd() might be a little
closer to conveying the meaning, but these work too, so your choice.

>+  /**
>+   * Flush a possible pending submission.
>+   */
>+  NS_IMETHOD FlushPendingSubmission() = 0;

Need more comment on what this means (even "See SubmitClickBegin above for more
information." would work).

>Index: html/content/src/nsHTMLButtonElement.cpp
>-  if ((NS_OK == ret) && (nsEventStatus_eIgnore == *aEventStatus) &&
>+  if ((NS_OK == ret) && 
>       !(aFlags & NS_EVENT_FLAG_CAPTURE)) {

Style nit: may as well move to NS_SUCCEEDED(ret), and put the !(aFlags...) on
the same line.

>+      case NS_MOUSE_LEFT_CLICK:
>+        {
>+          if (mForm) {
>+            if (mType == NS_FORM_BUTTON_SUBMIT) {
>+              // tell the form to forget a possible pending submission
>+              mForm->ForgetPendingSubmission();
>+              // tell the form immediatelly that subsequent submissions 
>+              // are not to be deferred
>+              mForm->OnSubmitButtonOrImageEnd();
>+            }

If you put the OnSubmitButtonOrImageEnd() that is currently below this spot up
before this whole switch(), you can avoid calling it twice.  It's done its job
once the onclick handler completes anyway.

Need comments as to *why* this is happening rather than *what*--i.e. "we are
doing the default action so we forget any submit()s that occurred during the
onClick--see bug 138957"

>+      switch (aEvent->message) {
>+        case NS_MOUSE_LEFT_CLICK:
>+        {
>+          if (mForm && mType == NS_FORM_BUTTON_SUBMIT) {
>+            // tell the form to flush a possible pending submission
>+            mForm->FlushPendingSubmission();
>+          }
>+        } break;// NS_MOUSE_LEFT_CLICK
>+      } //switch

You can remove the braces from this case statement and avoid the file style
issues the current version causes :)

Also, same as before--explain *why* we are flushing a submission here, since
the click submission is not going to go through we need to send any submit()
call that was called during the handler.

>+  if ( mType == NS_FORM_BUTTON_SUBMIT) {
>+    if (!(aFlags & NS_EVENT_FLAG_CAPTURE) &&
>+      aEvent->message == NS_MOUSE_LEFT_CLICK && mForm) {
>+      mForm->OnSubmitButtonOrImageEnd();
>     }
>   }

As noted before, this can be safely moved to just after JavaScript handlers
return, and you can save a bit of code and make it look a little neater, too.

>Index: html/content/src/nsHTMLFormElement.cpp
>+  /** Whether the submission was triggered by an Image or Submit*/
>+  PRPackedBool mButtonOrImageTriggered;
>+  /** Whether the submission was deferred*/
>+  PRPackedBool mSubmissionDeferred;

AFAICT you don't need mSubmissionDeferred--it is equivalent to mSubmission !=

>+  /** The submission object */
>+  nsCOMPtr<nsIFormSubmission> mSubmission;

This would be a good comment to expand on: "The pending submission object (so
that we can defer submit() if we are in a submit button click, see bug 138957)"

Also mPendingSubmission might be a better name.

This deferring of submission overall is very non-obvious and therefore need
better comments.

>+  /** the target*/
>+  nsAutoString mTarget;
>+  /** the Action URI*/
>+  nsCOMPtr<nsIURI> mActionURI;

We shouldn't need these, since any time you change action or target, you
immediately submit.

>@@ -522,6 +542,14 @@
> {
>   if (aName == nsHTMLAtoms::action || aName == nsHTMLAtoms::target) {
>     ForgetCurrentSubmission();
>+    if (mSubmissionDeferred) {
>+      // aha, there is a pending submission that means we're in
>+      // the script and we need to flush it. let's tell it
>+      // that the event was ignored to force the flush.
>+      // the second argument is not playing a role at all.
>+      FlushPendingSubmission();
>+      ForgetCurrentSubmission();
>+    }

How many times do we have to forget the current submission? :)	It's forgotten
once outside, once in FlushPendingSubmission, and then once again after Flush.

How about this instead:

if (mSubmissionDeferred) {
  // ...
// forget the current submission

We can get rid of the ForgetCurrentSubmission() in FlushPendingSubmission() by
re-re-factoring too ... seeing the code now I am thinking
ForgetCurrentSubmission() shouldn't have anything to do with pending submission
stuff--let's leave it for double submission protection only.

>@@ -558,6 +586,13 @@
>   nsCOMPtr<nsIPresContext> presContext;
>   GetPresContext(this, getter_AddRefs(presContext));
>   if (presContext) {
>+    if (mButtonOrImageTriggered) {
>+      // we will defer this submission after we walk
>+      // the elements to wait for JS to return
>+      mSubmissionDeferred = PR_TRUE;
>+    }

Can be safely removed, I believe, along with mSubmissionDeferred.

>@@ -808,55 +843,78 @@
>   if (aEvent) {
>     if (NS_FORM_EVENT == aEvent->eventStructType) {
>       originatingElement = ((nsFormEvent *)aEvent)->originator;
>+      if (originatingElement) {
>+      }

Remnant of lost code :)

>+  if(mSubmission) {
>+    // let's check if the stored mActionURI is javascript:
>+    // in that case we have to rebuild the submission
>+    // this prevents a recursion introduced by the sumission
>+    // deferral code
>+    PRBool schemeIsJavaScript = PR_FALSE;
>+    if (NS_SUCCEEDED(mActionURI->SchemeIs("javascript", &schemeIsJavaScript)) &&
>+        schemeIsJavaScript) {
>+      mSubmission = nsnull;
>+      mActionURI = nsnull;
>+    }
>+  }

I don't think this is necessary--we already have a recursion problem and you
won't be storing mActionURI anymore anyway.

>-  //
>-  // Dump the data into the submission object
>-  //
>-  rv = WalkFormElements(submission, originatingElement);
>+  nsresult rv;
>+  if (!mSubmission) {

OK, now we come to the reason you are using mSubmissionDeferred--you are trying
to actually submit mSubmission and building mSubmission if it is not built. 
Therefore by the time you want to check if there is a pending submission, you
are guaranteed to have already built one.  The solution to this is to not put
the submission into mSubmission unless you are deferring the submission.  It
could be something like (conceptually):

  if (mPendingSubmission) {
  nsCOMPtr<nsIFormSubmission> submission;
  Build submission
  if (mButtonOrImageTriggered) {
    mPendingSubmission = submission;
  SubmitBuiltSubmission(submission) (gets action, target, submits)

  if (mPendingSubmission) {
    mPendingSubmission = nsnull;

In the above algorithm I am also suggesting splitting out the submission part
into its own function so that FlushPendingSubmission() does not have to take
the confusing step of calling DoSubmit() when all it wants to do is submit the
pending submission.

>+    //
>+    // Get the action and target
>+    //

The part where you get action and target (and check them for javascript URI) no
longer needs to be in the if(), as noted in the algorithm above.

>+    // javascript URIs are not really submissions; they just call a function.
>+    // Also, they may synchronously call submit(), and we want them to be able to
>+    // do so while still disallowing other double submissions. (Bug 139798)
>+    // Note that any other URI types that are of equivalent type should also be
>+    // added here.

The check for "javascript:" URIs to disable mIsSubmitting must sadly be moved
into "Submit submission," but it's really a small price to pay for the

>+	ForgetCurrentSubmission();

Since nothing has been submitted, there should be no need to forget the current

>Index: html/content/src/nsHTMLInputElement.cpp
>+      case NS_FORM_INPUT_SUBMIT:
>+      case NS_FORM_INPUT_IMAGE:
>+        if(mForm) {
>+          mForm->OnSubmitButtonOrImageBegin();
>+        }
>+        break;

Comment here, as in nsHTMLButtonElement.

>@@ -1415,6 +1422,7 @@
>       aEvent->message == NS_MOUSE_MIDDLE_CLICK) {
>     aEvent->flags &= ~NS_EVENT_FLAG_NO_CONTENT_DISPATCH;
>   }

Intentional extra spacing?  Looks like a typo to me.

>@@ -1466,237 +1474,274 @@
>+  if ((NS_OK == rv) && 
>       !(aFlags & NS_EVENT_FLAG_CAPTURE)) {

As in nsHTMLButtonElement, NS_SUCCEEDED(rv) and put the two lines together.

>+      switch (aEvent->message) {
>+        case NS_MOUSE_LEFT_CLICK:
>+        {
>+          switch(type) {
>+            case NS_FORM_INPUT_SUBMIT:
>+            case NS_FORM_INPUT_IMAGE:
>+              {
>+                if (mForm) {
>+                  // tell the form to flush a possible pending submission
>+                  mForm->FlushPendingSubmission();
>+                }
>+              }
>+              break;
>+          }
>+        } break;// NS_MOUSE_LEFT_CLICK

Same as nsHTMLButtonElement.

>+  if (!(aFlags & NS_EVENT_FLAG_CAPTURE) &&
>+      aEvent->message == NS_MOUSE_LEFT_CLICK) {
>+    switch(type) {
>+      case NS_FORM_INPUT_SUBMIT:
>+      case NS_FORM_INPUT_IMAGE:
>+        if(mForm) {
>+          mForm->OnSubmitButtonOrImageEnd();
>+        }
>+        break;
>+    } //switch
>+  }

As in nsHTMLButtonElement, this ought to be just after the click handler, it's

Also if you do that you can remove the extra call to this function earlier in
this function.
Attachment #105825 - Flags: review?(jkeiser) → review-

Comment 59

17 years ago
Posted patch apliable patch WIP (obsolete) — Splinter Review
Attachment #105825 - Attachment is obsolete: true

Comment 60

17 years ago
Posted patch 5th working patch WIP (obsolete) — Splinter Review
Attachment #106266 - Attachment is obsolete: true

Comment 61

17 years ago
Attachment #106321 - Attachment is obsolete: true


17 years ago
Attachment #106322 - Attachment description: 6th working patch WIP (but probably final) → 6th working patch WIP (damn, forgot something)
Attachment #106322 - Attachment is obsolete: true

Comment 63

17 years ago
Comment on attachment 106328 [details] [diff] [review]
7th patch (obsoleted since jkeiser thinks there are still some issues)

i would go with this version of the patch. it got rid of all the unnecesary
stuff and it simplified a lot everything. it also does not require the
splitting of DoSubmit what I prefer. I tested it already and it works flawless
afaict. however if you still think we should split DoSubmit, i can do that too.
i think this version of the patch is still the one with the lesser bloat i
Attachment #106328 - Flags: review?(jkeiser)
Comment on attachment 106328 [details] [diff] [review]
7th patch (obsoleted since jkeiser thinks there are still some issues)

r=jkeiser with the following comments addressed:

+	     if ((mType == NS_FORM_BUTTON_SUBMIT || mType ==
+		 mForm) {

"&& mForm" not necessary here, it's done in the outer if().

+	  } else {
+      switch (aEvent->message) {
+	   if (mForm && mType == NS_FORM_BUTTON_SUBMIT) {


+//    ForgetCurrentSubmission();

Best to just delete it :)

+  if (!mPendingSubmission) {
+    return NS_OK;
+  }
+  nsCOMPtr<nsIPresContext> presContext;
+  GetPresContext(this, getter_AddRefs(presContext));
+  DoSubmit(presContext, nsnull);

I still don't like the fact that you've got that if() in DoSubmit(), because
it's fragile (if any other codepath goes into DoSubmit() while a pending
submission is sitting around, unexpected things will happen).  And it's
unclear--the function's job is to build and submit a submission except you're
using an if() to not build it.	This whole thing is a hack anyway (a
well-engineered hack, but a hack) so it needs to be as obvious as possible, and
intrude as little on normal codepaths as possible.

You can go this way and I'll r=, but if you do please put a big comment on the
DoSubmit() definition explaining that it submits the current submission
*unless* there is a pending submission, and a little comment in
FlushPendingSubmission() to explain that it's using that feature.

I need to play around with this patch some too, but I can do that while it's
going through sr.
Attachment #106328 - Flags: review?(jkeiser) → review+

Comment 65

17 years ago
Comment on attachment 106328 [details] [diff] [review]
7th patch (obsoleted since jkeiser thinks there are still some issues)

you don't have to play around with it. if you don't like it, then let's
obsolete it. i can work on your concenrs if you think something else could hit
that path while a submission is pending.  right now i don't see how that could
happen, but i will investigate.
Attachment #106328 - Attachment description: 7th patch, the lucky number → 7th patch (obsoleted since jkeiser thinks there are still some issues)
Attachment #106328 - Attachment is obsolete: true

Comment 66

17 years ago
here is (hopefully) the final patch:
- removed the unneccesary stuff from patch #7
- did cosmetical stuff
- big change from #7: splitted DoSubmit in DoSubmit, BuildSubmission,


17 years ago
Attachment #106751 - Flags: review?(jkeiser)
Comment on attachment 106751 [details] [diff] [review]
9th patch (8th patch not uploaded) 

Woohoo!  Here's to no more frivolous bug reports!
Attachment #106751 - Flags: review?(jkeiser) → review+


17 years ago
Attachment #106751 - Flags: superreview?(bzbarsky)

Comment 68

17 years ago
Comment on attachment 106751 [details] [diff] [review]
9th patch (8th patch not uploaded) 

jst, do you have time to sr= this. i tried first bz but he has a bunch of sr
requests in his queue and i might have some fixes that depend on this one. thx!
Attachment #106751 - Flags: superreview?(bzbarsky) → superreview?(jst)
If you want me to sr this then attach a patch that either writes the code in
nsHTMLInputElement::HandleDOMEvent() in a way that doesn't require re-indenting
a whole lot of code (by doing an early return if *aEventStatus ==
nsEventStatus_eIgnore), or attach a diff in -w form, I won't waste time going
through *hundreds* of lines of changes when there's no indication that most of
the changes are just indentation changes and I don't know that some real changes
are not hidden in there.

Send a new sr request when this is done and I'll see what I can do.

Comment 70

17 years ago
Posted patch same patch this time with -w (obsolete) — Splinter Review

Comment 71

17 years ago
Comment on attachment 107552 [details] [diff] [review]
same patch this time with -w

patch generated with -w for readability. sorry about the previous.
Attachment #107552 - Flags: superreview?(jst)
Comment on attachment 107552 [details] [diff] [review]
same patch this time with -w

Found a few nits, and one problem:

- In nsHTMLButtonElement.cpp:

@@ -464,6 +464,15 @@

+  if (mType == NS_FORM_BUTTON_SUBMIT && !(aFlags & NS_EVENT_FLAG_CAPTURE) &&
+     !(aFlags & NS_EVENT_FLAG_SYSTEM_EVENT) &&
+      aEvent->message == NS_MOUSE_LEFT_CLICK && mForm) {

and then a bit further down you have:

+  if (mType == NS_FORM_BUTTON_SUBMIT && !(aFlags & NS_EVENT_FLAG_CAPTURE) &&
+     !(aFlags & NS_EVENT_FLAG_SYSTEM_EVENT) &&
+      aEvent->message == NS_MOUSE_LEFT_CLICK && mForm) {

How about using a local boolean to hold the result of that whole expression to
avoid duplicating it. Also, that would fix the problem if someone changes the
type of the button from within the onclick handler from submit to reset, then
your code would never call OnSubmitClickEnd().

- In nsHTMLFormElement.cpp:

+nsHTMLFormElement::BuildSubmission(nsIPresContext* aPresContext, 
+				    nsCOMPtr<nsIFormSubmission>&
+				    nsEvent* aEvent) {

Move the opening brace ('{') down onto it's own line.

+nsHTMLFormElement::SubmitSubmission(nsIPresContext* aPresContext, 
+				     nsIFormSubmission* aFormSubmission) {

Same here.

@@ -870,7 +952,7 @@
   // Submit
   nsCOMPtr<nsIDocShell> docShell;
-  rv = submission->SubmitTo(actionURI, target, this, aPresContext,
+  rv = aFormSubmission->SubmitTo(actionURI, target, this, aPresContext,

Fix up the indentation of next-line arguments so that they line up with the
first argument.

@@ -1693,8 +1729,26 @@
+      switch (aEvent->message) {
+	   switch(type) {
+	     case NS_FORM_INPUT_IMAGE:
+	   } //switch
+	   break;// NS_MOUSE_LEFT_CLICK
     } //switch 
+    } //if
   } // if

Wouldn't this be *so* much easier to read with a single if check in stead of
two nested switch'es?

sr=jst if you fix the above.
Attachment #107552 - Flags: superreview?(jst) → superreview+

Comment 73

17 years ago
so, here is the final version of the patch with the changes reauested by jst:

- added the boolean flag (bInSubmitClick) in nsHTMLButtonElement.cpp to catch a
possible type change of the element (nice catch!)
- corrected the { for BuildSubmission and SubmitSubmission
- the indentation problem appeared only in the -w version of the patch
- replaced the if/switch/switch/if with one if (my intention initially was to 
keep the style of the previous block in front of else)

since you have a build environment and can apply the patch, it wouldn't be a
bad idea to test it a bit on your side. i will check it in this week though.
Attachment #106751 - Attachment is obsolete: true
Attachment #107552 - Attachment is obsolete: true

Comment 74

17 years ago
Comment on attachment 107730 [details] [diff] [review]
final version of the patch addressing jst's requests
{ r= jkeiser
sr= jst }
(for some reason, i couldn't type the right names in the requestee fields as i tried to move the r/sr flags to this patch - form control bug or bugzilla?)

moving the review flags (for some reason i cannot type the names in the fields,
will not them here:
r= jkeiser
sr= jst
Attachment #107730 - Flags: superreview+
Attachment #107730 - Flags: review+


17 years ago
Attachment #107730 - Attachment description: final version of the patch addressing jst's requests → final version of the patch addressing jst's requests r= jkeiser sr= jst (for soem reason, i couldn't type the right names in the requestee fields - form control bug or bugzilla?)


17 years ago
Attachment #107730 - Attachment description: final version of the patch addressing jst's requests r= jkeiser sr= jst (for soem reason, i couldn't type the right names in the requestee fields - form control bug or bugzilla?) → final version of the patch addressing jst's requests { r= jkeiser sr= jst } (for some reason, i couldn't type the right names in the requestee fields as i tried to move the r/sr flags to this patch - form control bug or bugzilla?)

Comment 75

17 years ago
fixed on trunk.
Closed: 17 years ago
Resolution: --- → FIXED

Comment 76

17 years ago
Verified with test on Careerbuilder site 2002113004 PC/Win98

Comment 77

17 years ago

if you know bugs that get fixed by this fix, please mark them as duplicates or
as fixed and make a note on this bug. thx!


17 years ago
Attachment #106751 - Flags: superreview?(jst)
Blocks: 192170
Posted file Bigass Testcase
This is the same as attachment 105037 [details] except pointed at a working form submit
receiving script.
Attachment #105037 - Attachment is obsolete: true
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.