22526 - [FIX]Enter in text input submits form only if there is exactly one text input

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[skliaroukp]

make enter button to submit form (excluding textarea tag)

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Currently enter only submits a form if it consists of a single text input, I
think.  I think it's that way for a reason - otherwise it's easy to accidentally
submit.  However, changing component to HTML Form Controls and reassigning in
case somebody wants to reconsider.

Comment 2

[karnaze (gone)]

If there is a single text field in a form then hitting the enter key will submit
the form. I'm not sure what the bug says. Eric, please check that this behavior
hasn't regressed.

Comment 3

[Eric Pollmann]

Yes, this still works.

But this reminds me of another bug I noticed on code inspection where we were
submitting on pressing enter in the last text input if there were an odd
number.  I'll attach a test case, and a fix - I'll put it in for M13.

Comment 4

[Eric Pollmann]

Attachment: Pressing enter in last text input submits but shouldn't

Comment 5

[Eric Pollmann]

This is for Nav compatability.  IE chose to allow enter to submit in any text
input.  I personally have mixed feelings on this, because Tab already has the
effect of moving from field to field and we really don't need Enter to do the
same, but I'll go with Nav backwards compatability for now.

Fix is:
Index: nsFormFrame.cpp
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsFormFrame.cpp,v
retrieving revision 3.88
diff -c -r3.88 nsFormFrame.cpp
*** nsFormFrame.cpp	2000/01/06 22:07:21	3.88
--- nsFormFrame.cpp	2000/01/07 06:54:00
***************
*** 365,371 ****
    // a solo text control can be a submitter (if return is hit)
    // XXX pollmann this logic is flawed - three text boxes?
    if ((NS_FORM_INPUT_TEXT == type) || (NS_FORM_INPUT_PASSWORD == type)) {
!     mTextSubmitter = (nsnull == mTextSubmitter) ? &aFrame : nsnull;
      return;
    }

--- 365,375 ----
    // a solo text control can be a submitter (if return is hit)
    // XXX pollmann this logic is flawed - three text boxes?
    if ((NS_FORM_INPUT_TEXT == type) || (NS_FORM_INPUT_PASSWORD == type)) {
!     if (mTextSubmitterCounter < 2) {
!       mTextSubmitterCounter++;
!       if (1 == mTextSubmitterCounter) mTextSubmitter = &aFrame;
!       else mTextSubmitter = nsnull;
!     }
      return;
    }

Index: nsFormFrame.h
===================================================================
RCS file: /cvsroot/mozilla/layout/html/forms/src/nsFormFrame.h,v
retrieving revision 3.26
diff -c -r3.26 nsFormFrame.h
*** nsFormFrame.h	1999/12/08 02:07:03	3.26
--- nsFormFrame.h	2000/01/07 06:54:01
***************
*** 109,114 ****
--- 109,115 ----
    nsVoidArray          mFormControls;
    nsVoidArray          mRadioGroups;
    nsIFormControlFrame* mTextSubmitter;
+   PRInt8               mTextSubmitterCounter;
  };

  #endif // nsFormFrame_h___

Comment 6

[Eric Pollmann]

Attachment: fix used

Comment 7

[Eric Pollmann]

I just checked in a fix for this bug.  Now we will submit when pressing Enter in
a text input if and only if there is exactly one text input in the form.

To verify, view the first attachment "Pressing enter in last text input...".
Click on the very last text input (third input in third form).  Type some text
then press Enter.  The form should *not* submit.  Now click on the very first
input (first input in first form).  Type some text then press Enter.  The form
*should* submit.  Thanks!

Comment 8

[Eric Pollmann]

See related bug 25300

Comment 9

[Eric Pollmann]

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

Comment 10

[Antti Näyhä]

Verifying Fixed on Win98 build 2000-04-09-08.  Will soon try it on Mac & Linux.

The Platform/OS for this bug should probably be All/All?  Please correct those 
if I'm wrong.

Comment 11

[Antti Näyhä]

Verified Fixed on Linux (build 2000-04-24-09) and Mac (build 2000-04-24-08).

Comment 12

[Eric Pollmann]

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

Comment 13

[Eric Pollmann]

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

Comment 14

[Eric Pollmann]

Bug 24842 has some interesting, alternative UI suggestions, such as Ctrl+Enter
to submit the form from any input field, or a drop-down menu choice "Submit
Form" with perhaps multiple entries, one per form on the page.

Comment 15

[Jesse Ruderman]

I noticed that you specifically decided to not allow enter to submit a form 
with multiple text elements, even if focus is in the last text field.  Why?

Comment 16

[Eric Pollmann]

This was for backwards compatability with Nav 4.x's behaviour.

Typically, if the user it at the last input, they simply need to tab to the
Submit button and press Enter or Space to submit the form.  The choice to go
with Nav's behaviour was based on the fact that is seemed less prone to
use-entry errors than IE's.

Your suggestion to allow Enter to submit the form when the focus is on the last
control is an interesting one.  I'd really like to get feedback from people on
what they think is the best combination of 1) speed for experienced users, 2)
accessability, and 3) safety from accidents by novice users.

As a more complex alternative, we could start some kind of user preferences pane
for hotkeys and keyboard shortcuts, or add a pref to Prefs->Advanced->Forms for
this.  There is already precedent for this granularity of control in
Prefs->Instant Messenger->Enter key inserts Return

Comment 17

[Matthew T (active 1999-2002)]

There are no Instant Messenger prefs in Mozilla, and if there were I'd file a bug 
on `Enter key inserts Return' being a silly pref (it should be a twisty in the 
message pane itself).

I disagree that letting Enter submit a multi-field forms is `prone to
use[r]-entry errors'. If you think it is, then please file a bug to remove the 
Enter keybinding from default buttons for all dialogs in Mozilla which have more 
than one textfield -- HTTP authentication dialogs, the prefs dialog, the New 
Bookmark dialog, etc. There's no reason that content should behave differently 
from chrome in this regard. 4.x's refusal to submit multi-field forms when Enter 
was pressed was one of 4.x's most annoying aspects.

Suggested spec:
* If any form control other than an <input type="button"> or <input type="reset">
  is focused, and Ctrl+Enter is pressed, the first <input type="submit"> in the
  form should be activated (e.g. the `Google Search' button on
  <http://www.google.com/>).
* If any form control other than an <input type="submit">, <input type="reset">,
  or <textarea> is focused and Enter is pressed, the first <input type="submit">
  in the form should be activated.
* If an <input type="submit"> or <input type="reset"> is focused and Enter or
  Ctrl+Enter is pressed, that control should be activated.
* If a <textarea> is focused and Enter is pressed, a carriage return character
  should be entered in the field.
* Default appearance (e.g. a thicker border) should be given to whichever
  <input type="submit"> or <input type="reset"> will respond to the Ctrl+Enter
  combo based on the above rules, depending on the current focus (see also bug
  63728).
* The omission of <input type="button"> and <button> from responding to Enter in
  the above rules is deliberate -- they are analagous to the `toolbuttons' which
  in Windows respond to Space but not to Enter (and in Mac OS have a rectangular
  border instead of a rounded one).

Comment 18

[Eric Pollmann]

Removing past milestone

Comment 19

[Tim Powell]

I have to agree with Matthew Thomas (mpt) that letting Enter submit the form is 
a good idea. In addition to all the things he mentioned, when new users submit 
a form there's the warning dialog that appears about sending information. So 
there's really no danger to letting it submit the form.

Still this seems to be getting somewhat away from the point of this bug. Should 
one be logged specifically about allowing Enter to submit forms? This could  be 
a pref so Mozilla could mimic either NS4.x behavior or IE.

Comment 20

[Matthew T (active 1999-2002)]

tpowell, this *is* the point of the bug. Enter only submits the form if there 
is exactly one textfield; if there are more, it doesn't. No other browser I've 
tried (except for 4.x) behaves like this. It's annoying.

Comment 21

[Eric Pollmann]

mpt: Do all of the browsers you mentioned (ie, icab, opera), all submit the form
when Enter is pressed on any input except Textarea?  (Just trying to get more
data on the severity of the problem)

Comment 22

[Matthew T (active 1999-2002)]

They all submit the form on Enter if focus is in a single-line text field. IE 
for Mac doesn't submit the form if focus is on a radiobutton or checkbox, but 
this feels like a bug.

Comment 23

[Eric Pollmann]

I wonder if that IE/Mac behaviour is intentional - can Enter be used to select
an unselected radio or toggle a checkbox?  Is this a Mac UI expectation?  (This
is what we do in Mozilla)

Coincidentally, it would simplyify things a reasonable amount both in code and
user expectation if we followed IE/Mac's logic - all single-line text and
password fields submit on Enter, all buttons, checkboxes, and radios are
activated on Enter (form not submitted unless the button happens to be a
submit), Enter in a Textarea inserts a linebreak.

Enter in Combobox does ? (drops it down?)  Enter in list box does ? (selects
current highlighted entry?)

It would be nice if the user only thought "Enter means activate this control"
and in the case of single-line text inputs, Enter means submit.

At any rate, there are years of contrary precedent in Netscape browsers here, so
I like the idea of having a pref with ui for this...

Comment 24

[Matthew T (active 1999-2002)]

> can Enter be used [in IE/Mac] to select an unselected radio or toggle a
> checkbox?

Yes.

> Is this a Mac UI expectation?  (This is what we do in Mozilla)

Then that's a bug, because it's not a Mac UI expectation (where you can't 
usually focus a radiobutton/checkbox at all), *or* a Windows UI expectation 
(where Enter will activate the default button, not the radiobutton/checkbox),
*or* a GTK UI expectation (where Enter will activate the default button, not 
the radiobutton/checkbox).

> It would be nice if the user only thought "Enter means activate this control"
> and in the case of single-line text inputs, Enter means submit.

Why only allow submitting of a form when in a single-line text field? That 
makes no sense.

It's Space which means `activate this control' in native UIs, not Enter.
accel+Enter should always activate the default button, and so should Enter 
(except in multi-line text fields, of course).

> At any rate, there are years of contrary precedent in Netscape browsers here,
> so I like the idea of having a pref with ui for this...

If a pref is introduced, I'll file a bug to get rid of it.

Comment 25

[Boris Zbarsky [:bzbarsky]]

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[mdimitrio]

I had a friend of mine, who has Internet access, visiting me at home, and she
wanted to check her email. So I thought to myself, what a great oportunity to
test Mozilla in a real life situation, so I opened Mozilla for her. <ot>She said
"wow, what's this?", me: "It's Mozilla, another browser I use, I have 4 browsers
installed", she: "<g>Oh, you have to be different, don't you?</g>". I like her
;-)</ot>

She went to mail.yahoo.com, clicked the yahoo id field, filled that field,
tabbed to the password, filled that too and pressed ENTER. And it didn't get sent.

I'm telling you this because this is a behavior that people, the general user,
come to expect, and something I miss in NS Communicator too, not just an "Opera
and IE do it, lets do it too" argument. So, that's why I think it's an important
issue, and should be implemented ASAP.

Marcos.

Comment 28

[jsp]

For what it's worth, I've been puzzled for years as to under what circumstances
which browser would submit a form when Enter was pressed. Now I almost always
activate whatever submit button there is. I may be addled by a profusion of
browsers, but I think it's important to come up with an easily understood,
predictable behavior. For me, the obvious approach would be "Enter submits the
form, unless the element with focus preempts." The element might preempt because
it's a form control that makes use of the Enter key (like a textarea or a submit
button), or because it has an event handler that prevents the default action (by
calling DOM2's Event.preventDefault()).

I think this is just an abstraction of mpt's proposal, which makes sense to me.

Comment 29

[timeless]

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

Comment 30

[Tuukka Tolvanen (sp3000)]

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

Comment 31

[Ben Goodger (use ben at mozilla dot org for email)]

Regardless of the Netscape 4.x precedent, the Netscape 4.x behaviour should be 
considered a bug in 4.x, and not a baseline. We diverge in many areas, and 
diverging in this area would ease transition for the (hopefully) many IE users 
who try to use the product, and for web authors who currently have to script 
this behaviour. 

I suggest we find a way to tackle this before 1.0. It's trivial, but it's also 
a *significant* annoyance and impediment to web usability. 

Comment 32

[njvack]

Personally, the current behavior of Mozilla feels quite broken. I'm used to IE's
form behavior; it feels natural. Spent an hour debugging my forms today before I
realized that there was no way I could fix them to work... just a simple
username/password pair of boxes.

I personally feel that enter in a form should submit. Text boxes don't always
need input (Bugzilla's query form is a shining example).

I'd be happy if enter in a single-line textbox never submitted a form, or if it
always did; the current "sometimes" behavior is confusing. It's not even always
obvious from page layout what textboxes live in what forms; currently,
predicting browser behavior is hard.

Just my $.02.

Comment 33

[Eric Pollmann]

Attachment: patch 2: make behavior controllable via pref (only text inputs submit with this patch, not radios/checkboxes)

Comment 34

[Eric Pollmann]

Attachment: patch 3: add to patch 2 to make Checkboxes and Radios also submit on Enter press

Comment 35

[Eric Pollmann]

Attachment: patch 4: add to patch2 or (patch2+patch3) to make Enter Always Submits the default

Comment 36

[njvack]

Eric, you rule.

Comment 37

[Blake Ross]

What's the status on this? Can we get it checked in? It was a big complaint from
6.1pr1.

Also, can we please not make this a pref?  There's no reason to pref everything
to satisfy one or two people in bug reports who disagree.  In general, prefs
should not be used to resolved arguments, unless they're warranted, in which
case they'd have UI.

Comment 38

[Blake Ross]

+              if (keyEvent->keyCode != NS_VK_SPACE) {

May want to consider just making that a check for return, in case we ever want
to handle more keys.

sr=blake if you remove the pref aspect

Comment 39

[Eric Pollmann]

> +              if (keyEvent->keyCode != NS_VK_SPACE) {
>
> May want to consider just making that a check for return, in case we ever want
> to handle more keys.

If we do handle more keys, they should be added to the outer if (outside the
switch that contains the case containing this if), not this one.  I figured that
the most likely key to be added to this 'keys that trigger inputs' block was
NS_VK_ENTER, in which case we *would* want to submit the form, rather than
triggering the input.  That's why I chose to to != NS_VK_SPACE.

As for the pref, I'll remove the code that creates/checks the pref, and all of
the other code made useless by no longer allowing only singular text inputs to
submit.  This will at least force the issue early on, and if there are too many
screams from Netscape old-schoolers (which I would not expect), we can send them
to this bug report and have them argue for a pref.

Patch coming...

Comment 40

[Eric Pollmann]

Attachment: patch 5: Enter submits anywhere, no pref.

Comment 41

[mdimitrio]

> patch 5: Enter submits anywhere, no pref.

Anywhere, but not in textarea and check/radio boxes, right?

Comment 42

[Eric Pollmann]

Not in textarea, select, or button controls.

It will submit in both checkboxes, radioboxes, and single line inputs (including
password inputs).

I believe this is IE's behavior.

Comment 43

[mdimitrio]

> Not in textarea, select, or button controls.

Unless that button is type=submit, I suppose, am I right? If I am, then yes,
that's the IE behavior.

Marcos.

Comment 44

[Eric Pollmann]

Marcos: yes, unless the button is a submit.  :)

Comment 45

[mdimitrio]

Oh, good then :)

Marcos.

Comment 46

[Blake Ross]

Eric, can you get this reviewed and checked in?

Comment 47

[Eric Pollmann]

Blake, does your sr= still apply to patch 5?  It's a bit different in that it
removes all the code obsoleted by this change as well.  :)

Comment 48

[Johnny Stenback (:jst)]

r/sr=jst

Comment 49

[Eric Pollmann]

Fix checked in.  To verify, view the first attachment on this bug report. 
Pressing Enter in any of the text controls should submit the corresponding form.

Comment 50

[Matthew T (active 1999-2002)]

Reopening and raising severity to blocker. I don't have a current Mac build to
test on, but testers on both Linux and Windows report that this fix submits the
form even when focus is in a multi-line text field. As I explicitly noted in my
2001-01-25 comment, this should not happen; Control+Enter should still submit
the form, but plain Enter in a textarea should just insert a new line.

Among other things, this makes current builds practically unusable in Bugzilla.

Comment 51

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

smoketest blocker

Comment 52

[Håkan Waara]

I say let's back this out for now.

Objections?

Comment 53

[Eric Pollmann]

Fix in hand, sorry for not seeing this sooner, I'll get this reviewed and in ASAP...

Comment 54

[Eric Pollmann]

Attachment: Patch, don't submit on Enter press in textarea

Comment 55

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

r=dbaron

Comment 56

[Simon Fraser [no longer active]]

sr=sfraser

Comment 57

[Eric Pollmann]

Fix checked in.  Sorry for any surprise submits this may have caused!  To
verify, press Enter inside a textarea, like the Additional Comments: textarea on
this bug report - the form should not be submitted.

Comment 58

[Chase Tingley]

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

Comment 59

[Vladimir Ermakov]

verifying build 2001-08-27-03-trunk windows 98

Comment 60

[Ron Cemer]

You're forgetting a HUGE piece of the puzzle:
What if there is NO submit button?  What if I want to control form submission by
JavaScript using "document.entryform.submit()"?
Pressing [Enter] on an input element should NEVER cause an automatic submit(),
unless that element is of type "SUBMIT".  If a web page wants to submit the form
based on any action, JavaScript can easily be used to do it.  But having the
Enter key submit the form automatically, basically prevents Mozilla from being
able to be used to repetitively enter groups of numbers.  The numeric keypad has
an [Enter] key.  A common method for moving between fields on the form is to
trap the [Enter] key and treat it the same as [Tab].  Now you've broken this. 
And worse yet, if the user presses Enter on a form, there's no way to trap and
cancel the submit operation because the onSubmit="... return false" is now
broken also.

Comment 61

[Jesse Ruderman]

[e-mail]: so vote for the bug about onsubmit="...return false;" being 
broken (file one if you can't find it, and attach a testcase).  By the way, I 
think there's a way to trap the enter keypress and tell Mozilla to ignore it, 
but I don't know the syntax offhand.

Comment 62

[rods (gone)]

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

Comment 63

[rods (gone)]

Needs to be reopened

Comment 64

[rods (gone)]

Attachment: testcase

Comment 65

[rods (gone)]

taking bug

Comment 66

[rods (gone)]

Attachment: proposed change

Comment 67

[Christopher Blizzard (:blizzard)]

OK, just to get this straight, here's what the behaviour should be:

If a single text field exists in a form and a user hits return then the form
should submit, even if there's a submit button.  The submit button is _not_
included in the form post data. ( Can you say ISINDEX? )

If there's more than one text field the enter should either not submit the form
or else include the "first" button on the form as part of the submit data.

Rod, is that what that patch does?

Comment 68

[kinmoz]

You can avoid adding the GetFormFrame() method if you just pushed this check:


+      // Now check to see how many input text and password fields we have
+      // and if there is more than one, don't submit
+      nsFormFrame* formframe = mFrame->GetFormFrame();
+      if (formframe != nsnull && formframe->GetNumInputText() == 1) {
+        mFrame->SubmitAttempt();
+      }


into nsGfxTextControlFrame2::SubmitAttempt() and combined it with the existing
logic that determines whether or not to actually do the submit.

Comment 69

[kinmoz]

> If a single text field exists in a form and a user hits return then the form
> should submit, even if there's a submit button.  The submit button is _not_
> included in the form post data. ( Can you say ISINDEX? )


Yes. It looks like IE does this, as well as Nav 4.x. The submit button is not
included unless you actually pressed it.

GetType() on and ISINDEX widget returns the same type as a normal textfield, so
rod's patch should work with ISINDEX.


> If there's more than one text field the enter should either not submit
> the form or else include the "first" button on the form as part of the
> submit data.


This is where 4.x and IE differ. 4.x will *not* submit when you hit return in a
form that contains more than one textfield, password, or isindex field. Looks
like IE does.

Comment 70

[Tim Powell]

Rod, if I'm reading your proposed change correctly, you're unfixing this bug 
which has made it so Enter submits the form no matter what field you're in 
(except textareas) and regardless of how many fields there are. If I'm correct, 
you're just going back to Netscape 4.x behavior. The point of this bug was to 
get rid of Netscape 4.x behavior. I like it that Enter submits the form 
regardless. That's why this bug was logged. 

>> If there's more than one text field the enter should either not submit
>> the form or else include the "first" button on the form as part of the
>> submit data.

> This is where 4.x and IE differ. 4.x will *not* submit when you hit return
> in a form that contains more than one textfield, password, or isindex 
> field. Looks like IE does.

And Mozilla did after this bug was fixed. Why is it being changed? I suspect 
I'm missing something. Your changes seem to undo the fix for this bug. 

Comment 71

[rods (gone)]

Attachment: new patch with Kin's suggestions

Comment 72

[Boris Zbarsky [:bzbarsky]]

OK. We've got 4 different behaviors here, if I understand correctly:

1)  Old Mozilla and NS4.  Only submits on enter if the only form control is a
    single textfield.  If there are any checkboxes or the like present, enter
    does not submit.
2)  New Mozilla (current behavior).  Enter submits in every form control except
    textarea (and reset, I presume).  If enter is hit when not on a submit
    button, no submit button data is sent to the server
3)  IE.  Just like #2 except a submit button is selected as the button to send
    to the server.  If there is only on submit button, this is exactly
    equivalent to the user clicking submit.  If there are several, IE makes a
    choice somehow (no IE here, so can't test how)
4)  Mozilla behavior with Rod's patch.  Just like #2 except submit will only
    occur if there is one and only one text/password input.  Note that this
    means that a form with 30 checkboxes and one text input _will_ be submitted.
    A form with 30 checkboxes and no text inputs will _not_ be submitted.  A
    form with 30 checkboxes and 2+ text inputs will _not_ be submitted.  In all
    cases, no info is sent about submit buttons.

The reason this bug was reopened is that blizzard is arguing that we should be
doing #3 instead of #2 because #2 will break some sites.  Going to #4 is not the
right solution to this problem -- it's, imo, a lot worse than #2 because of the
inconsistencies in whether we submit which people will perceive when they try to
use forms.

Comment 73

[Christopher Blizzard (:blizzard)]

> 
> This is where 4.x and IE differ. 4.x will *not* submit when you hit return in a
> form that contains more than one textfield, password, or isindex field. Looks
> like IE does.
 
IE does submit when you hit return but it includes one of the buttons as part of
the post data.  Like I've said before I'm not exactly sure how IE determines
which one to send in this case and because of that ambiguity I would personally
recommend that we go back to the old 4.x behaviour.  ( If there's more than one
form element that we don't submit on enter. )

Given that you guys are getting close to shipping you need to resolve this
quickly.  If we want to investigate it further after that point please do but
it's important this this get fixed for the branch otherwise you guys are going
to ship a product that breaks in subtle ways on lots of sites and will piss of
web developers since it's going to break lots of web navigation.

Comment 74

[Tim Powell]

It appears that there's some confusion about N4.x's behavior. Boris Zbarsky 
description is inaccurate.

1) Netscape 4.x will submit the form when you press enter in a text or password 
field if there's only one text or password field. You can have any number of 
other controls and Enter will still submit the form. For example, 
http://hotbot.lycos.com/ lets you change many search options, but still submit 
the form by typing a search term and pressing enter. This is because it uses 
only one text field.

Notice that 4) is now basically identical to 1). 4) seems to be in direct 
contradiction to this bug, and as Boris notes, 4 doesn't seem to have anything 
to do with fixing the problem of which submit button to send. The only thing it 
does is make it extremely unlikely that you can use Enter to submit the form, 
so you have to pick the "real" submit button.

I believe we should either stick with 2) or try to mimic IE's behavior (3). If 
we go with 3, I'd hope we could fix bugzilla so that the query page works 
correctly when pressing enter. I've gotten spoiled with Mozilla's current 
behavior. IE doesn't seem to be able to submit the query with enter.

If I understand the problem correctly, perhaps we could check for multiple 
submit buttons instead of multiple text/password fields. If there's only one 
submit button, there's no reason that Enter couldn't submit the form and use 
that submit button. If there's multiple submit buttons, then either we try to 
mimic IE behavior or perhaps Enter shouldn't work regardless of how many 
text/password fields there are (not that I like this idea).

Comment 75

[Jesse Ruderman]

I would be annoyed (as would many other NS4 and IE users) if Google's "I'm 
feeling lucky" button prevented me from doing a normal search with enter.

Comment 76

[Tim Powell]

Jesse, you're right, that would annoy me too. :-) In the comment by Christopher 
Blizzard 2001-09-25 11:44, he notes that in a form with a single text field, 
Enter should submit and no submit button data should be included. This is IE 
and netscape 4.x's behavior. I believe Rod's patch already does this.

Do we just need someone to investigate IE behavior?

Comment 77

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Removing smoketest keyword, which is from the previous time this bug was
reopened, not this one.

Comment 78

[rods (gone)]

I should not have reopened this bug, it is fine.

Comment 79

[Vladimir Ermakov]

verifying 2001-10-03 branch

Comment 80

[Matthew T (active 1999-2002)]

Sorry to be a pain, but this has regressed. In build 2001100508, Mac OS 9.1,
Enter no longer submits a form if there is more than one text field. (Let me
know if I should file a separate bug on the regression and re-close this one.)

Comment 81

[Boris Zbarsky [:bzbarsky]]

mpt, the regression is covered in bug 99920, which has a patch.

re-resolving.

Comment 82

[Tim Powell]

Mozilla no longer submits a form when pressing Enter in every form element
(behavior 2 in comments by Boris Zbarsky 2001-09-25 13:22, and I believe the
patch checked in for this bug). Enter only works in text/password fields. See
bug 104449.

Comment 83

[Vladimir Ermakov]

verifying on windows 98 2001-10-24-05-trunk