104211 - Solve form submission on ENTER ambiguity

Status: REOPENED

(Core :: DOM: Core & HTML, enhancement, P4)

Description

[[e-mail]]

When Enter was originally added to Form Submission it broke some websites
because all of their submit buttons have names and their CGI expects to see one
of them.

So this was fixed by always submitting the first submit button or image.
This "breaks" the bugzilla query page because the first button is "Or".
What I would like is for enter to search for an unnamed submit button or image.
This button should be submitted in preference to any named submit button or image.

Comment 1

[Tim Powell]

If the goal is to make bugzilla work by submitting on Enter, then perhaps a
duplicate of bug 28763? Moving the submit button will also fix IE. I would
recommend not looking for special types of submit buttons. As I understand it,
Mozilla is intentionally mimicking IE behavior so that we don't drive web
developers crazy.

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[[e-mail]]

Oh, so we should mimic all IE's mistakes, then?

Comment 4

[Simon Brooke]

Look, this is extremely badly broken behaviour. If no 'submit' widget was pressed, 
no submit widget was pressed, and 'guessing' which one the user would have pressed if 
they had pressed one has to be the wrong thing to do. If other people's scripts are 
broken that's their problem and they can fix it. Do *not* break the browser! (and 
don't mimic broken behaviour by other browsers, either).

If the user presses 'enter' on a single text input in a form, *no* submit button 
value should be sent. Not the first, not an unnamed one, none at all.

Comment 5

[Dan Tobias]

I'll second the comments that Mozilla should be attempting to implement web
standards in a logical and consistent manner, not emulating the misfeatures of
competing browsers.

Comment 6

[rods (gone)]

I certainly think it is a bug if we select the first submit and it doesn't have 
a name.

We can argue whether the new behavior (like IE) is broken or not but we are 
trying to provide a consistent browsing experience to make life easier for web 
developers (and not grossly deverge from the spec) The concenses was, this was a 
good thing to do.

Comment 7

[rods (gone)]

reassinging to new owner of form submission

Comment 8

[[e-mail]]

For those of you not in the know, if a submit button does not have a name then
clicking the button submits the form without a submit value, as per the old
behaviour. This should explain why I want the form to submit without a submit
value, should such a button exist anywhere on the form.

Comment 9

[[e-mail]]

query.cgi design is not relavent to the scope of this bug.

Comment 10

[Alexander Schuettelkopf]

It should be pointed out that in a form with one text input and several 'input
type=image' buttons, but no submit button, pressing enter in the text input
submits 'l.x=0&l.y=0' (assuming the first image button has the name 'l', tested
on Mozilla 0.9.6 and 0.9.7). Not even IE is that broken.

The new behavior is clearly undesirable as it makes it *impossible* to
differentiate between submission by pressing enter and submission by clicking
the 'first' button, which can be a severe limitation to form design. The old
behavior OTOH simply requires an additional trivial-to-implement test on the
server side.

Comment 11

[John Keiser (jkeiser)]

Hitting enter and choosing a submit button based on fixed criteria when there
are multiple submit buttons is a misfeature from the get-go.  We should not be
choosing the first anything, whether it's unnamed or named.  It must be
configurable.  Two ways we could do it:

- use the tab order (undesirable for the same sorts of reason that you shouldn't
just choose the first submit button, though at least this allows the web
developer to choose and preserves IE-compatible behavior)
- get HTML to add a "submitonenter" attr (this is the hard but preferable path)
and don't submit any of the buttons if there are multiple buttons and this attr
is not set (or use IE's behavior in that case :( )

Comment 12

[[e-mail]]

> add a "submitonenter" attr

What about default="true"?

While I realise that choosing between named submit buttons is a problem,
choosing between unnamed submit buttons should not be a problem because their
values are never sent to the CGI anyway.

Comment 13

[[e-mail]]

Note that the IE 5 behaviour is for Enter to trigger onsubmit, and then send the
name=value pair of the first button in the form. IMHO this is only right if
there is only one submit button on the form.

Comment 14

[Vladimir Ermakov]

this is a duplicate

*** This bug has been marked as a duplicate of 28763 ***

Comment 15

[Dave Miller [:justdave]]

This issue is requesting changes to Mozilla, not Bugzilla.  If the changes are
not going to be made to Mozilla, this should be WONTFIXed, not marked as a
duplicate of a Bugzilla bug.  Inter-product duplicates are just nasty, people.

Comment 16

[Jesse Ruderman]

When a form contains multiple submit buttons, IE sometimes sends no button on
enter (http://www.google.com/) and sometimes sends the first button
(http://bugzilla.mozilla.org/query.cgi?format=classic).  Netscape 4 doesn't
accept the Enter key at Bugzilla but does at Google.  What's the difference
between Google and Bugzilla?  (Opera and Mozilla send the first button in both
cases.)

Comment 17

[[e-mail]]

AFAIK when IE sees a form with only one textbox it submits it without a button,
possibly for 4.x compatibility.

Comment 18

[Vladimir Ermakov]

Changing summary based on comments, particularly #11

Comment 19

[Jamie Wilmoth]

Yes, the best would probably be to work simular to an application input form (at
least under Windows) where hitting Enter selects the 'default button.'  What
we're missing is a means to select that, rather than just picking the first.  As
it is, I have a form with a number of different submit buttons, and the one I
want as the default one is at the bottom.

Or better yet, have a special value returned when the user hits enter, to make
it quite clear to the server side script what occured.  It would be author
selectable by such as

<INPUT TYPE="ENTERSUBMIT" NAME=".." VALUE="...">

which would act as a hidden field as far as displaying, but act as the activated
submit button when enter is used to submit.  This should be backwards compatible
with other current and old browsers as it'd be ignored as an unknown type and
behave as usual (for that browser).

A work-around I'm going to try, now that I see there is no 'good' solution, is
of the likes:

<INPUT TYPE="SUBMIT" NAME="EnterSubmit" VALUE="1" STYLE="display:none">

and place it as the first control in the form.  (You may replace the NAME/VALUE
to match that of your submit button that you want as the default if don't need
to know enter was used.)  The drawback with this is for browsers not honoring
the STYLE setting.  (Just tried it, and does currently work in Mozilla 203030305.)

Comment 20

[Boris Zbarsky [:bzbarsky]]

First, I don't think we want to be making up new HTML attributes here.

Second, the goal of the current behavior is to not break sites while allowing
enter in most inputs to submit (unlike NS4).   That means doing what IE does
(see the "not break sites" part).

I don't see a single suggestion in this bug that leads to more "intuitive"
behavior, really (apart from extending HTML some and letting the page author
specify the default button).  So I don't see compelling arguments to change what
we do.

Comment 21

[Hixie (not reading bugmail)]

The proposed changes to HTML aren't backwards compatible.

I don't see anything wrong the defining the default submit button as being the
first submit button in the form's controls array.

Can someone study IE's behaviour with respect to image buttons and tell me what
it does? Does it skip past image buttons? Does it use them for submission? What
about <input type="submit"> vs <button type="submit"> ? Does it include both in
its concept of default button?

Whatever IE does is what I'm likely to specify in Web Forms 2.0.

Comment 22

[Michael Tibben]

Hi, has any progress been made here?
Can anyone explain what the behaviour of Mozilla/Firefox is at present with
regards to choosing a submit on Enter being pressed? it seems it simply chooses
the first submit button... is this correct?

as a web developer, i personally like the idea of using the tab order to select
the submit button. This gives me control over what button is used to submit...

Thanks

Comment 23

[Boris Zbarsky [:bzbarsky]]

> Can anyone explain what the behaviour of Mozilla/Firefox is at present

It's explained in comment 13, basically.  We take the first submit or image
control and dispatch a click event to it; this ends up submitting the form
exactly as if that control were clicked.

> i personally like the idea of using the tab order to select the submit button

Unfortunately, that would break compat with IE (and hence quite possibly break
some sites).

Comment 24

[Michael Tibben]

(In reply to comment #23)
ok thats cool, so how does the developer specify the submit button to use? cos
i'm buggered if i can work it out....

surely there has to be a way to do this, it really doesn't seem like this should
be a difficult issue to get around...

Comment 25

[Boris Zbarsky [:bzbarsky]]

You can always catch the keypress, dispatch a click to the button of your
choosing, and cancel the keypress.

Comment 26

[Frédéric Buclin]

(In reply to comment #12)
> > add a "submitonenter" attr
> 
> What about default="true"?

Personally, I like both solutions, especially the second one:
<input type="submit" default="true" name="foo" value="bar">

If there is no button with the default="true" (or default="1") attribute, select the first button of the form, as we actually do (backward compatible); if there is more than one button with this attribute, select the first one of them (assuming the web developer didn't realise he put this attribute twice); if there is only one button with this attribute, that's the one. :)

This would really help when the button you expect to be clicked is the last one of the form (as in editflagtypes.cgi in Bugzilla).

Actually, you give no chance to the web developer to get the desired effect, and putting the "default" button as the first one in the form is not always the best solution (bad UI).