If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED

Status

()

Core
Layout: Form Controls
P4
normal
VERIFIED FIXED
16 years ago
15 years ago

People

(Reporter: Peter Jamieson, Assigned: John Keiser (jkeiser))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [FIX])

Attachments

(3 attachments, 1 obsolete attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Created attachment 85433 [details]
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
(Reporter)

Comment 2

16 years ago
Created attachment 85434 [details]
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
(Reporter)

Comment 3

16 years ago
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

16 years ago
john is this form controls?
(Assignee)

Comment 5

16 years ago
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.
Assignee: alexsavulov → jkeiser
Component: Form Submission → HTML Form Controls
Depends on: 125578
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.
(Assignee)

Comment 7

16 years ago
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 :)
Would this fire the onclick handler of the button?
(Reporter)

Comment 9

16 years ago
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.
(Assignee)

Comment 10

16 years ago
It would fire onClick, yeah.  Just like clicking the button would.
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.
(Assignee)

Comment 12

16 years ago
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.
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.  ;)

Updated

16 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 14

16 years ago
Created attachment 86195 [details] [diff] [review]
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.
(Assignee)

Updated

16 years ago
Whiteboard: [FIX]
> +    * (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?).
(Assignee)

Comment 16

16 years ago
Created attachment 86248 [details] [diff] [review]
Patch v1.0.1

Fixes bz's comments.
Attachment #86195 - Attachment is obsolete: true
Comment on attachment 86248 [details] [diff] [review]
Patch v1.0.1

r=bzbarsky
Attachment #86248 - Flags: review+
Comment on attachment 86248 [details] [diff] [review]
Patch v1.0.1

sr=jst
Attachment #86248 - Flags: superreview+
(Assignee)

Comment 19

16 years ago
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 20

16 years ago
Personally I would prefer searching for a submit button without a name first
before any other algorithm you come up with.
(Assignee)

Comment 21

16 years ago
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

16 years ago
verifying build 2002-07-01-08-trunk windows 98 and 2002-07-02-04-trunk on Linux
Status: RESOLVED → VERIFIED

Comment 23

16 years ago
*** Bug 139599 has been marked as a duplicate of this bug. ***
*** Bug 158828 has been marked as a duplicate of this bug. ***

Comment 25

15 years ago
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?)
(Assignee)

Comment 26

15 years ago
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).
You need to log in before you can comment on or make changes to this bug.