form should NOT submit when there is more than one text field in the form and the user hits enter in a text field




HTML: Form Submission
17 years ago
17 years ago


(Reporter: Kevin McCluskey (gone), Assigned: Chak Nanga)



Firefox Tracking Flags

(Not tracked)




(2 attachments)



17 years ago
This bug was taken from

If there is more than one text field on a page then hitting enter in a text
field should not trigger a form Submit.

If there are other web pages which rely on the enter key for form submission
from a text field(even when there are multiple text elements on
a page) then they have to either TAB to the submit button or click on the submit
button for form submission. This is what the spec says and is what NS 4.x does.


17 years ago
Keywords: edt0.9.4

Comment 1

17 years ago
Created attachment 70105 [details] [diff] [review]
Patch to submit iff we have one text field and a submit button

Chak's patch from bugscape 12109

Comment 2

17 years ago
Cc:ing rods, kin since they worked on the original bug

Comment 3

17 years ago
Adding url to rod's comprehensive submit test case from bug 99920,
attatchment 51057:

Comment 4

17 years ago
Note that this bug is in direct contrast to bug 22526.

The patch makes it so that you can only submit if there is only one 
textfield *and* a submit button. In 4.x you could submit without a submit button 
defined for the form.

In the bugscape bug, Ken says he can still crash, although it's not as easy then 
without this patch.

What's the proposal for this patch? 094 branch only? My guess is that if it went 
into the trunk there would be lots of complaints.

Comment 5

17 years ago
The current proposal is we fix it just on the 0.9.4 branch.

Comment 6

17 years ago
OK, this is a stopgap, and it should work to fix the underlying problem reported
in Bugscape.  The reason we are submitting when there are multiple textfields is
IE does it that way.

Is there any real reason to deny submission on single-textfield forms without
submit buttons?  That seems like a bad idea.  (I think sites rely on that
behavior.)  To get the real effect you want, you should change the line to:

+ if (inputTxtCnt == 1) {

I recommend we do *not* apply this to the Mozilla tree.

Comment 7

17 years ago
(By "do not apply to Mozilla tree" I meant to the Mozilla trunk.)

Comment 8

17 years ago
Created attachment 70126 [details] [diff] [review]
Updated patch to submit  when we have only a single text field - even without a Submit button

If everyone agrees that it's OK to checkin this updated patch only to the 0.9.4
branch can i pls get an r=/sr=/a= ?

Comment 9

17 years ago
Comment on attachment 70126 [details] [diff] [review]
Updated patch to submit  when we have only a single text field - even without a Submit button

Attachment #70126 - Flags: review+

Comment 10

17 years ago
Wait, I think the problem is an event observer/listener ordering problem. 
Checking in this fix only makes the problem less noticeable with multiple 
textfields ... it doesn't fix the problem. If my theory is correct, you should 
be able to reproduce this problem with the text case in the bugscape bug, with a 
single textfield and some hidden input values.

Comment 11

17 years ago
By event ordering, I mean that the keypress handler defined on the password 
field should be fired first, before the default text control handling which does 
a submit on return ... I think the default handling is happening before the 
keypress handler is fired so that is why we are getting the double dialogs.
Yes, you will see the double submit problem with one textfield.  My
understanding is that this is intended to get it to work with specific pages
(which means to me that they will have a username field as well)--I haven't
heard any complaints about this on the Mozilla side that I can remember.

I don't think it's an ordering problem, however.  As it stands, whether the
password submit() happens before or after the submit, it's still going to cause
a submit.  And no matter when the keypress frames code fires, it's still going
to cause a submit.

The problem is we don't short-circuit.  Ever.  That's the bigger double-submit
problem (bug 72906).

The underlying problem we are trying to "fix" (read: work around) right here is
bug 76605, which is dependent on 72906.

A *good* real fix to 72906 is non-trivial.  This at least emulates NS4.x
behavior, so there is some justification for it even in a 0.9.4 branch.

Comment 13

17 years ago
Comment on attachment 70126 [details] [diff] [review]
Updated patch to submit  when we have only a single text field - even without a Submit button

Ok, I'll sr=kin this with the understanding that this is a workaround for the
mozilla0.9.4 branch ONLY.

Do we have to worry about this impacting any other customers that may be using
the 0.9.4 branch?
Attachment #70126 - Flags: superreview+

Comment 14

17 years ago
This is 0.9.4 branch only workaround, but we'll have to face the real resolution
before the next Netscape release is shipped. Could somebody nominate the right
bug (using the right magic keyword)?

Comment 15

17 years ago
It's already been nominated and (+)'ed see bug 72906.

Comment 16

17 years ago
Marking it edt0.9.4+ (i.e., approval for 0.9.4 check-in).
When could we get this in?
Keywords: edt0.9.4 → edt0.9.4+

Comment 17

17 years ago
fix checked in to 0.9.4 branch...
Last Resolved: 17 years ago
Resolution: --- → FIXED


17 years ago
Keywords: fixed0.9.4

Comment 18

17 years ago
Ran through tests on this, so far so good. Ran through logins/submits on large 
sites, such as,,,,, (not a complete list). Ran through form submit 
test cases. No new issues discovered so far. 

Comment 19

17 years ago
Verifying build 2002-02-22-03-trunk windows 2000, build 2002-03-01-03-trunk win 98 
You need to log in before you can comment on or make changes to this bug.