147850 - pressing enter on a text entry box in a field acts inconsistently

Status: VERIFIED FIXED

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

Description

[Peter Jamieson]

I have a 2 pieces of HTML code which contain forms.

The first has a submit button, followed by a text entry field and then another
button with the same name as the previous.
The second is similar but has 2 text entry fields.

On both pages, i set the focus to a text entry field and press the enter key.

The page with 2 text field acts as if i pressed the first submit button and
posts the data accordingly.
The page with 1 text entry field does not post any data for the submit buttons.

Comment 1

[Peter Jamieson]

Attachment: HTML form with 1 text field

Load this into a browser and press return in the text entry field.
in the target url, there is no entry for the "name=query" button

Comment 2

[Peter Jamieson]

Attachment: HTML form with 2 text entry fields.

Load this into a browser and press return in either of the text entry fields.
in the target url, there is an entry "query=Fred" which is inconsistent with
the previous HTML example

Comment 3

[Peter Jamieson]

I tried the HTML with IE6 and Opera

IE acted the same as mozilla
Opera acted as i would expect and send the first submit button no matter how
many text fields there were

Comment 4

[Alexandru Savulov]

john is this form controls?

Comment 5

[John Keiser (jkeiser)]

I think we can safely diverge from IE here, but we should speak to the original
implementors.  This problem was introduced with enter-submits-form behavior in
bug 99920 and specifically not fixed in bug 109463.

bz, Rod, what do you think?  Is it all right to go with Opera here and always
click the submit button when there is one, even if there is only one text field?
 It definitely seems more consistent to me.

P.S. don't bother making a patch until bug 125578 is fixed--it moves this logic
over to nsHTMLInputElement.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Doing that will break sites, I'm afraid.  The number of sites that do their own 
(intolerant) parsing of form input is pretty high.  As a note, IE has this 
bizarre behavior to be compatible with NS4.  In NS4, the only way to submit a 
form via "enter" in a textfield is if there is only one textfield.  In such 
cases the submit button is not sent.

So we can be compatible with Opera on the one hand, and with IE/NS4 on the 
other.  I vote for compat with the latter, myself.

Comment 7

[John Keiser (jkeiser)]

Servers *have* to be tolerant enough to parse the button value when the user
does this, because they have to handle the user clicking the submit button
directly as well.

Given that it should be absolutely zero impact, and that it makes *sense*, I
vote for doing it.  I am not concerned with compatibility with Opera, just sanity :)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Would this fire the onclick handler of the button?

Comment 9

[Peter Jamieson]

It seems that in one the case where it sends the submit button id, it also fires
the onClick method.

I'd hoped this wasn't the case because i wanted to try and disable enter
submitting the form.

As an aside, i got consistent behaviour by making all the buttons "type=button"
rather than submits and calling this.form.submit() in the onClick method.  enter
does nothing if they are all like this.

Comment 10

[John Keiser (jkeiser)]

It would fire onClick, yeah.  Just like clicking the button would.

Comment 11

[Boris Zbarsky [:bzbarsky]]

So... that seems like a gratuitous incompatibility to introduce with NS4 and IE 
(neither of which fires onclick).

I'm all for making this consistent, but the compat issues worry me.

Comment 12

[John Keiser (jkeiser)]

What I am saying is:

(1) all forms that would be affected have a submit button to click
(2) if the user clicks on the submit button the form has to fire onClick and
submit the submit button value anyway
(3) if we introduce this, we will simply be using the normal route of processing
in the form when someone clicks on the button.  It is an incompatibility but it
is an overwhelmingly sane one and I can see no reason why it would break anything.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Agreed on all 3 counts, sure.

You're right that the chance of something going wrong is pretty low... I just 
spent about 30 minutes coming up with possible scenarios that would break and 
pretty much failing.  I'm convinced.  Go for it.  Should be pretty simple.  ;)

Comment 14

[John Keiser (jkeiser)]

Attachment: Patch

This fixes it.	I have tested everything in bug 99920 and bug 109463 and
everything works as expected--i.e. everything works as before *except* cases
where there is one textfield and submit button--in those cases it fires onClick
/ onSubmit.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> +    * (b) if there is just one text control in the form, submit by sending
> +    *     a click.

You mean submit by just submitting, right?

The rest looks good. One thing that gives me pause is the part about "// Find 
the nearest submit control in elements[]" (the comment before that searching 
loop).  What we find is the _first_ submit control in elements[], no?  I 
suppose we could handle that in a separate bug (what does IE do?).

Comment 16

[John Keiser (jkeiser)]

Attachment: Patch v1.0.1

Fixes bz's comments.

Comment 17

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 86248 [details] [diff] [review]
Patch v1.0.1

r=bzbarsky

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 86248 [details] [diff] [review]
Patch v1.0.1

sr=jst

Comment 19

[John Keiser (jkeiser)]

Fix checked in to trunk.

Comment 20

[[e-mail]]

Personally I would prefer searching for a submit button without a name first
before any other algorithm you come up with.

Comment 21

[John Keiser (jkeiser)]

There is no reason why a submit button with a name is more likely to be clicked
than one without.  In fact, there are good reasons why it is not.  Submit
buttons without names are often used as the "default" submit button.

Comment 22

[Vladimir Ermakov]

verifying build 2002-07-01-08-trunk windows 98 and 2002-07-02-04-trunk on Linux

Comment 23

[Vladimir Ermakov]

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

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Joe M]

If this is simulating a click, shouldn't it focus on the submit button first?
(for example, what if a script does validation onfocus instead of onclick?)

Comment 26

[John Keiser (jkeiser)]

Validation on focus of the submit button?  Never heard of it.  We certainly
*could* change the focus but that might be jarring to the user (in a way that a
click does not).