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.
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
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
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.
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. ;)
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.
> + * (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?).
Created attachment 86248 [details] [diff] [review] Patch v1.0.1 Fixes bz's comments.
Comment on attachment 86248 [details] [diff] [review] Patch v1.0.1 r=bzbarsky
Comment on attachment 86248 [details] [diff] [review] Patch v1.0.1 sr=jst
Fix checked in to trunk.
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
*** 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).