Closed Bug 156683 Opened 18 years ago Closed 18 years ago
Enter in text inputs should fire on
Click but not add submit id to URL (e .g . &btn G=Google+Search)
281 bytes, text/html
To reproduce: 1. Go to <http://www.google.com/intl/en/>. 2. Type "foo" (without quotes), and press Enter. 3. Look at the resulting URI. What you should see: * http://www.google.com/search?hl=en&ie=ISO-8859-1&q=foo What you actually see: * http://www.google.com/search?hl=en&ie=ISO-8859-1&q=foo&btnG=Google+Search Problem occurs with: * Mozilla nightly build 2002070608, Mac OS 9.2.2 Does not occur with: * Microsoft Internet Explorer 5.1.4, Mac OS 9.2.2 This makes Google (and any other form using GET) less usable in two respects. 1. Mozilla URIs are longer (harder to parse, more likely to break when pasting in e-mail, blah blah blah.) 2. For Mozilla-based browsers, Google has to refrain from saying `Tip: In most browsers you can just hit the return key instead of clicking on the search button', since it can no longer tell whether you clicked the search button or not. <bz> mpt9728: because IE fires onclick <bz> mpt9728: and so we need to fire onclick <mpt9728> yes, but onclick != putting the button in the URI <bz> mpt9728: so when you hit enter the textfield dispatches a click event to the button <mpt9728> It should not <bz> mpt9728: there is no other way to fire the button's onclick in the current event architecture.... <mpt9728> FIX IT
OS: Mac System 9.x → All
Priority: -- → P1
Hardware: Macintosh → All
Target Milestone: --- → mozilla1.2alpha
What is the problem with this behaviour? If pressing enter simulates submitting the form with a button it should simulate it all the way, so that there is no difference between pressing enter and clicking submit button. I would say the IE's behaviour is broken because it does not submit the value for the button. There are cases where this value is used in the script to determine what action to take and getting rid of this value would break the script. This is invalid, unless there is a good reason to do this, like a standard that says we should do this.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → INVALID
Not only that, but pressing enter in a textfield is not something web page designers are supposed to worry about (unless they want to do keypress). The reason enter fires onClick is so that we do something they *do* expect--i.e. simulate the user clicking the submit button.
*** Bug 155216 has been marked as a duplicate of this bug. ***
Status: RESOLVED → VERIFIED
*** Bug 182549 has been marked as a duplicate of this bug. ***
The current behavior (a) is not required by the HTML specification, (b) is inconsistent with the behavior of browsers used by approximately 98 percent of Web users (making the suggestion that it is `not something web page designers are supposed to worry about' patently false), and (c) is producing undesirable results in Web sites. Therefore, it is a bug. Reproduced in build 2002120108, Windows 98. Reopening.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
(d) does not make sense.
mpt, what you're talking about was an explicit decision made in bug 147850 to make the onclick rules make sense. We fire onclick elsewhere. Look at these testcases in IE: http://bugzilla.mozilla.org/attachment.cgi?id=51057&action=view And tell me that we're not supposed to submit the name/value pair with submit buttons. The fact that IE does not submit them in this Google case is a *bug*,. If we're going to follow their model, which is to make sure you click a button when one exists, then we should follow it consistently--better than they do. The reasons for this have already been mentioned: web designers shouldn't have to code differently for this *completely unspecified* function. It is easy to imagine servers that are written with clicking in mind that don't work with keypresses because it *hasn't been tested*. So there are bad consequences to *not* doing it the way that. Now let's go over the "bad consequences": (a) longer URLs on keypress: give me a break! Pressing enter is the way you create smaller bookmarks? I don't think we need to support your idiosyncracies; if Google doesn't require that extra parameter, they can bloody well not send it. (b) Google can always catch onkeypress and do form.submit() to show that little hint. Not showing that hint is not enough reason to introduce a potential bug for other websites. That is simply an evangelism problem, and a minor one at that. Not enough reason to fix, and there are reasons not to fix.
OK, fine, WONTFIX instead of INVALID. The bug in IE, for those interested, is that if you have an input type=hidden in a form, enter does *not* fire onclick but if you do, it *does*. This rule has absolutely no sense behind it that I can see, and has the aforementioned problems. Reopen if you can find a way to argue it.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 18 years ago
Resolution: --- → WONTFIX
*** Bug 187042 has been marked as a duplicate of this bug. ***
[Resummarizing in an attempt to minimize duplicates.]
I agree that IE's behavior makes no sense. I also agree that submit button parameters should be passed when (and only when) a submit button is clicked (whether that event is implicitly or explicitly fired). But I believe Mozilla's behavior doesn't make sense either. Why should pressing enter simulate clicking a submit button? Pressing enter submits the form; there is no simulation involved. It seems that there's been worry about unexpected behavior if a button click is not simulated. 1.If that worry has to do with scripting, then the script author should use onsubmit for the form rather than onclick for the button. 2.If it has to do with a page handling one operation, then submit button parameters don’t matter anyway; the page only does one thing. 3.If it has to do with one page handling multiple types of operations depending on the submit button parameters then: a)If the operations are divided into separate pages which point to the same action page, then hidden inputs are more appropriate than submit button parameters. b)If the operations are on the same page where there are multiple submit buttons, Mozilla has no place to decide which button to use. To me, picking whichever button happens to be first would cause more unexpected behavior than not picking a button at all. The action page should handle submissions in which the user does not make a distinct submit choice with an error page clarifying to use a submit button or with some default action. HTML is not the type of language in which first means default. This is true of checks in radio buttons, for example. If the default is not *defined*, it cannot be *assumed*. What, then, is the argument FOR simulating submit button clicking? A proper site author has all the options to easily include submissions that have no submit button parameters within expected behavior. Breaking sites should not take precedence over doing what is right and, IMO, most logical. By adopting this behavior, Mozilla is actually limiting web developers. What if an author wants his action page to react differently when a submission is related and is not related to a submit button click? This idea, though far-fetched, was actually one of the staples of an AI chat site. Unfortunately, I can’t find the site now, but hopefully my description will be adequate. When the user pressed enter to submit, the button parameters weren’t passed. The AI computer responded with an angry "why didn’t you click my submit button!?" page. With Mozilla’s behavior, this page CANNOT function properly without unnecessary scripting. This also means this page will not work with browsers that follow Mozilla’s behavior and do not have or have not enabled scripting support. The attachment below is an example of why Mozilla should not assume a button with which to submit (3b above). Of course, it’s kind of silly to have the delete button before edit, but again, Mozilla is not the one to decide what a web designer should do. If I want my delete button to the left of my edit button, but I don’t want an errant enter press to delete, I shouldn’t need to learn a bunch of CSS to get it looking right. Again, Mozilla should not be limiting web developers. If Mozilla was acting properly, I should be able to put delete to the left of edit, and when a user presses enter, my default action (when I don’t receive a submit button parameter) will be to edit (as described in 3b). Expected behavior is that pressing enter does not submit button parameters. If a page does not consider that possibility, then the bug lies in that page, NOT Mozilla.
> Why should pressing enter simulate clicking a submit button? Because that's what IE does, and sites depend on browsers doing it. Since there is no spec on the matter, we go for compatibility with existing browsers. More to the point, I am a page author. I write an html form. I provide a submit button to submit the form. The browser provides a way to submit the form without triggering the submit button. I should not have to care that the browser chooses to do this weird thing... to me it should just look like my form was submitted.
That depends on the definition of "appropriately written page". I'm not sure what Opera's behavior is, but Netscape 4 does _not_ submit forms when enter is placed if there are multiple textboxes. So when we implemented this feature in Mozilla, the only guide we really had to go with was IE's behavior (since there is no specification covering the issue). The same goes for page authors. So now you're a page author and you write a page. You put a single submit button in the page. You have multiple text fields, so the HTML2 spec quote of yours does not apply. It is a reasonable assumption on the basis of the HTML specs that the only way submission could happen is when the submit button is clicked. You hook some client-side script to the onclick event of that button that does something to the submission. You expect this script to be fired on all submissions and guess what? you're correct -- it is, since IE made sure to fire the onclick handler of the button in cases like this one. Now along comes Mozilla; we duplicate the "enter submits" behavior but do _not_ fire onclick on the submit control. We get bugs on dozens of sites that break (look them up). Since there is no spec, we go and implement exactly what IE has implemented (yes, we had that set up for a while). Now we're firing the onclick on the button and submitting the button except in cases when there is only one text input, in which case we don't do it, because IE does not do it, becase Netscape 3 did not do it. The code to handle this is hairy and complicated and leads to unpredictable behavior from a page author perspective. So we change the behavior of one single case -- the case when there is only one text input. Too bad google is exactly such a page. The change we make does _not_ cause any problems for well-written pages that are not relying on the onclick of the button not being fired (because that would be dumb; people can click the button). The only drawback is that in the case when you have only one text input control you suddenly have the button being submitted. This is only an issue if you have multiple submit buttons in that form... and if the one you want to default to is not the first one. Yes, it could be a problem under those odd circumstances. The point is, all of this behavior is _not_ defined by the HTML spec, so we have to fall back on doing what we think makes the most sense. I would suggest putting your efforts into making sure that XForms does a better job of standardizing form submission....
Opera's behavior (7.0b1) is the same as Mozilla's currently (which is why I wrote `browsers used by approximately 98 percent of Web users' rather than `browsers used by approximately 99 percent of Web users' in comment 6). Which is, IMO, one way in which Opera fails to be less badly designed than Mozilla. Unfortunately I think my imprecise previous summary sidetracked this bug report into a discussion (e.g. comment 9) of when onClick should or should not be fired. That is IRRELEVANT to the actual bug. Read comment 0 again: > <mpt9728> yes, but onclick != putting the button in the URI The over-long URI is all I care about. Currently, however, Moz's architecture is such that a submit URI can only be constructed from within the onClick code; differentiating between keyboard and mouse submission would require adding an extra parameter to that function. Which is why, if this bug ever gets fixed, it will be by a maintainer who gives usability and internal elegance different weightings from the current maintainer. In the meantime, please do not waste bytes complaining (though a patch would help embeddors focusing on usability).
*** Bug 200029 has been marked as a duplicate of this bug. ***
I would like to add that I feel that IE's behaviour on Google's search page is strictly compliant with HTML 4.0 (and as such, is the "correct" behaviour when enter is pressed in a text input for a form with multiple submit buttons): http://www.w3.org/TR/REC-html40/interact/forms.html#successful-controls There is "more than one submit button", and causing one of them to submit values when makes it extremely hard to design a web-page with multiple submit buttons and text inputs. Now, really, the difficulty comes from allowing form submission when enter is pressed in a text input. This isn't a behaviour that is explicitly specified in HTML 4.0. Though it is _implied_ in the part about succesful controls, where it is implied that a form could be submitted without any submit buttons being "successful" For IE to not submit the name=value pairs for ANY submit buttons is correct when none of the submit buttons has been activated. Whether this is a coincidence or not isn't that important. I'm not sure if this is the specific IE bug you discuss here, but either way, IE's behaviour is "correct" (whether or not Mozilla's is also correct) Another place this bug creates completely nonsensical form parameters sent to a server is if there are multiple IMAGE inputs in a form. Pressing enter in a text input will fill in one of the IMAGE inputs as though it was clicked by the mouse at coordinates (0,0) (measured from the top left of the image). This not only falsely tells the webserver that a specific submit button has been pressed (which is bad enough, IMO), but is also falsely tells the webserver that another specific action occured: that the mouse was at a very specific coordinate on that submit button. It doesn't even pick an "impossible" value that might be detectable as an error condition. Now, I do find it odd that IE will pick a submit button if there is more than one text input, but not if there is only one text input. This _probably_ stems from the HTML 2.0 page cited in comment 15 (notably, this scenario wasn't in the attachment cited in comment 8). I would "propose" that it would be consistent for Mozilla to behave differently for forms with only one text input and multiple submit buttons. Though this consistency is dependant on a behaviour that is _very_ legacy. I would suggest, though, that something about this issue be brought up with w3, to give them a chance to deal with the ambiguity here. Overall it seems to me that using any of the submit values when enter is pressed is a kludge, but one that must be kept for compatibility. Regards, Sam
Sam, there is nothing odd about IE's behavior. If there is only one textfield, then they are submitting for compat with NS4 and have to mimic the NS4 behavior of not clicking the button. If there are multiple textfields, they do something simple -- use the button to submit. The one-textfield behavior is just a quirk in IE to be compatible with NS4.
Additionally, it is not the W3C's job to deal with what mouse buttons and keypresses do. That is the user agent's job. This is why the W3C talks about "activation" rather than "clicking." Anything you want can activate a button. You could hook it up to a decaying uranium atom for all the W3C cares. It's just that users are used to clicking and enter keypresses doing it.
Obviously, John. Just like it is possible to submit a form by manually changing the focus to a submit button and then using a keypress to submit it, or in an OS supporting touch-screens, tapping the screen (etc etc). Feel free to mentally substitute anywhere I have said "mouse press", "click", "enter" or "press enter" with "activate". The issue, rephrased per the above, and somewhat clarified, is that the w3 has not clearly indicated how (or indeed, whether) a text input would be "activated" in any recent HTML specs, nor have they defined what should occur if such an "activation" occurs. Clearly, there is some ambiguity here, otherwise it would be simple to say that IE's behaviour is non-compliant (in addition to being inconsistent). It would be enough for them to simply specify that "activating" a text input causes the first submit button to "succeed", or even some other stranger result, such as prohibiting activation of text inputs. Has any thought gone towards how image buttons, specifically, are handled in this case, though? Sending a plausible x,y to the server seems even further removed from the intended "feedback" for form submission. Regards, Sam
*How* the button is activated is still not something the W3C should specify. image buttons work the way IE does them, for better or worse. It broke a site or two when we didn't include them (admittedly not major ones--it could be changed). But it does the same thing that pressing enter on an image button does (try it--tab to an image button and press enter) so it seems semi-reasonable. Obviously we can't guess a spot on the image to click.
I agree. For all I care, you could activate screen elements by using baseball hand-signs (if I touch my nose, then my chin...) or by imitating various animals, or via telepathy. Who cares. Whether or not text fields in forms can be activated and what happens when they are is the issue that I think needs standardization, not the "how" of it. I thought that was pretty plain from my last reply? As to image buttons, I guess 0,0 could just be considered "indeterminate" coordinates fairly safely (most forms that will rely on precise coordinates, a- la image-maps won't have any other user-manipulable inputs). I guess it would be nice to have a "standard" "activation with no in-range coordinates", or "input device provides no coordinates" value-set to use, but again, that's a W3 thing (If they think it is needed.. *shrug*), not Mozilla. Regards, Sam
*** Bug 200587 has been marked as a duplicate of this bug. ***
*** Bug 270620 has been marked as a duplicate of this bug. ***
*** Bug 253704 has been marked as a duplicate of this bug. ***
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.