Closed Bug 147850 Opened 22 years ago Closed 22 years ago

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

Categories

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

x86
Windows NT
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: peter.jamieson, Assigned: john)

References

Details

(Whiteboard: [FIX])

Attachments

(3 files, 1 obsolete file)

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.
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
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
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
john is this form controls?
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.
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?
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.
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.
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.  ;)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Status: NEW → ASSIGNED
Attached patch Patch (obsolete) — Splinter Review
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.
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?).
Attached patch Patch v1.0.1Splinter Review
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+
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Personally I would prefer searching for a submit button without a name first
before any other algorithm you come up with.
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.
verifying build 2002-07-01-08-trunk windows 98 and 2002-07-02-04-trunk on Linux
Status: RESOLVED → VERIFIED
*** Bug 139599 has been marked as a duplicate of this bug. ***
*** Bug 158828 has been marked as a duplicate of this bug. ***
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?)
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.

Attachment

General

Creator:
Created:
Updated:
Size: