make enter button to submit form (excluding textarea tag)

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.

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.

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.

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___

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!

See related bug 25300

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

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.

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

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

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

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.

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?

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

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).

Removing past milestone

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.

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.

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)

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.

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...

> 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.

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

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

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.

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.

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

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

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.

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.

Eric, you rule.

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.

+ 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

> + 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...

> patch 5: Enter submits anywhere, no pref. Anywhere, but not in textarea and check/radio boxes, right?

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.

> 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.

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

Oh, good then :) Marcos.

Eric, can you get this reviewed and checked in?

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. :)

r/sr=jst

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.

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.

smoketest blocker

I say let's back this out for now. Objections?

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

r=dbaron

sr=sfraser

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.

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

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

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.

ron@roncemer.com: 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.

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

Needs to be reopened

taking bug

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?

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.

> 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.

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.

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.

> > 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.

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).

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.

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?

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

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

verifying 2001-10-03 branch

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.)

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

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.

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