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

Status: VERIFIED FIXED

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

Description

[Kevin McCluskey (gone)]

This bug was taken from http://bugscape.netscape.com/show_bug.cgi?id=12109

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.

Comment 1

[Kevin McCluskey (gone)]

Attachment: Patch to submit iff we have one text field and a submit button

Chak's patch from bugscape 12109

Comment 2

[Chak Nanga]

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

Comment 3

[kinmoz]

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

  http://bugzilla.mozilla.org/attachment.cgi?id=51057&action=view

Comment 4

[kinmoz]

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

[Chak Nanga]

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

Comment 6

[John Keiser (jkeiser)]

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

[John Keiser (jkeiser)]

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

Comment 8

[Chak Nanga]

Attachment: 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

[John Keiser (jkeiser)]

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

r=jkeiser

Comment 10

[kinmoz]

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

[kinmoz]

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.

Comment 12

[John Keiser (jkeiser)]

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

[kinmoz]

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?

Comment 14

[Marek Z. Jeziorek]

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

[Kevin McCluskey (gone)]

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

Comment 16

[Marek Z. Jeziorek]

Marking it edt0.9.4+ (i.e., approval for 0.9.4 check-in).
When could we get this in?

Comment 17

[Chak Nanga]

fix checked in to 0.9.4 branch...

Comment 18

[Jennifer Kobayashi]

Ran through tests on this, so far so good. Ran through logins/submits on large 
sites, such as www.aol.com, www.hotmail.com, www.msn.com, www.expedia.com, 
www.m-w.com, www.superpages.com (not a complete list). Ran through form submit 
test cases. No new issues discovered so far. 

Comment 19

[Vladimir Ermakov]

Verifying build 2002-02-22-03-trunk windows 2000, build 2002-03-01-03-trunk win 98