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)
Tracking
()
VERIFIED
FIXED
People
(Reporter: peter.jamieson, Assigned: john)
References
Details
(Whiteboard: [FIX])
Attachments
(3 files, 1 obsolete file)
186 bytes,
text/html
|
Details | |
220 bytes,
text/html
|
Details | |
2.77 KB,
patch
|
bzbarsky
:
review+
jst
:
superreview+
|
Details | Diff | Splinter Review |
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•22 years ago
|
||
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•22 years ago
|
||
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•22 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•22 years ago
|
||
john is this form controls?
Assignee | ||
Comment 5•22 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.
Comment 6•22 years ago
|
||
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•22 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 :)
Comment 8•22 years ago
|
||
Would this fire the onclick handler of the button?
Reporter | ||
Comment 9•22 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•22 years ago
|
||
It would fire onClick, yeah. Just like clicking the button would.
Comment 11•22 years ago
|
||
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•22 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.
Comment 13•22 years ago
|
||
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•22 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 14•22 years ago
|
||
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•22 years ago
|
Whiteboard: [FIX]
Comment 15•22 years ago
|
||
> + * (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•22 years ago
|
||
Fixes bz's comments.
Attachment #86195 -
Attachment is obsolete: true
Comment 17•22 years ago
|
||
Comment on attachment 86248 [details] [diff] [review] Patch v1.0.1 r=bzbarsky
Attachment #86248 -
Flags: review+
Comment 18•22 years ago
|
||
Comment on attachment 86248 [details] [diff] [review] Patch v1.0.1 sr=jst
Attachment #86248 -
Flags: superreview+
Assignee | ||
Comment 19•22 years ago
|
||
Fix checked in to trunk.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 20•22 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•22 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•22 years ago
|
||
verifying build 2002-07-01-08-trunk windows 98 and 2002-07-02-04-trunk on Linux
Status: RESOLVED → VERIFIED
Comment 23•22 years ago
|
||
*** Bug 139599 has been marked as a duplicate of this bug. ***
Comment 24•22 years ago
|
||
*** Bug 158828 has been marked as a duplicate of this bug. ***
Comment 25•22 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•22 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.
Description
•