156683 - Enter in text inputs should fire onClick but not add submit id to URL (e.g. &btnG=Google+Search)

Status: RESOLVED WONTFIX

(Core :: DOM: Core & HTML, defect, P1)

Description

[Matthew T (active 1999-2002)]

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

Comment 1

[Vladimir Ermakov]

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.

Comment 2

[John Keiser (jkeiser)]

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.

Comment 3

[Vladimir Ermakov]

*** Bug 155216 has been marked as a duplicate of this bug. ***

Comment 4

[Vladimir Ermakov]

verifying

Comment 5

[Matthias Versen [:Matti]]

*** Bug 182549 has been marked as a duplicate of this bug. ***

Comment 6

[Matthew T (active 1999-2002)]

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.

Comment 7

[John Keiser (jkeiser)]

(d) does not make sense.

Comment 8

[John Keiser (jkeiser)]

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.

Comment 9

[John Keiser (jkeiser)]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

*** Bug 187042 has been marked as a duplicate of this bug. ***

Comment 11

[Matthew T (active 1999-2002)]

[Resummarizing in an attempt to minimize duplicates.]

Comment 12

[Joe M]

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.

Comment 13

[Joe M]

Attachment: Example of why Mozilla shouldn't send submit button parameters on enter

Comment 14

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 15

[Joe M]

>Because that's what IE does, and sites depend on browsers doing it.
Not true; sites depend on what IE does, and we are not doing what IE does. IE
submitted button parameters with multiple text inputs but not with single ones.
Why should Mozilla imitate behavior of multiple text inputs more than single
text inputs? The bug report shows a clear instance of a major site's
"incompatibility" that Mozilla has been willing to tolerate.

>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...
Like I've said, a good author should not rely on the button's being clicked as
an indication of submission. I've laid out the different scenarios and what an
author should do in each. If one chooses to detect clicks instead of
submissions, that is the fault of the author.

>to me it should just look like my 
>form was submitted.
Exactly, your form is submitted, and it looks like it was submitted. But a
button click and parameters should not be simulated.

Going way back to the orginal spec that defined the enter key for form
submission (http://www.w3.org/MarkUp/html-spec/html-spec_8.html#SEC8.2):

"When there is only one single-line text input field in a form, the user agent
should accept Enter in that field as a request to submit the form."

This does not call for simulating a click on the first submit button.
Conformity, which by Mozilla's inconsistency with IE appears more important than
compatibility, would suggest that pressing enter should never click the submit
button.

From http://www.w3.org/TR/html4/interact/forms.html#h-17.13.2:

"If a form contains more than one submit button, only the activated submit
button is successful."

The usage of the word "only" infers that any submit button that is not activated
must not be successful. Pressing the enter key is not an instance of the user's
activating the submit button.

If you're unconvinved by the "activate" terminology, consult
http://www.w3.org/WAI/GL/Glossary/:

"To execute or carry out one or more behaviors associated with a component of
the user agent user interface."

"An active element is an element with behaviors that may be activated (or
'triggered') either through the user interface or through scripts."

Those are the only two components that should *activate* submit buttons. Mozilla
is triggering user behavior, but only users and scripts should be able to do so.
Simulating a click is a quintessential example of what Javascript is for, not
user agents.

More opinions from http://ppewww.ph.gla.ac.uk/%7Eflavell/www/formquestion.html:

"I can't see any justification based on the HTML4.01 specification for
considering a submit control that has not been used, to be a 'successful
control' in the terms of this specification."

"If those authors are writing broken scripts, then they better fix them, rather
than expecting Mozilla to sort them out by imitating illogical behaviour found
in some other browser-like object [IE], no matter how popular it might be."

"...if the submit control was not used for performing the submission, then in my
view it is not a 'successful control'..."

"There's nothing to beat designing your server-side scripts defensively, rather
than just making them work in the specific situations you tested and hoping that
the rest would take care of themselves."

No attempt has been made to refute the argument presented through the
attachment. Currently, there is no way to reliably determine which, if any,
button was used to submit a form. I see this as a limitation. Doing what's
popular should never take precedence (unless it's standardized) over giving the
greatest breadth of design possibilities to authors. With your being an author
yourself, I would have expected you to appreciate this opinion more.

I'm at ends to find an instance where not simulating a click and not submitting
button parameters would cause unexpected behavior for an appropriately written
page. Can you furnish an example?

Comment 16

[Boris Zbarsky [:bzbarsky]]

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....

Comment 17

[Matthew T (active 1999-2002)]

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).

Comment 18

[John Keiser (jkeiser)]

*** Bug 200029 has been marked as a duplicate of this bug. ***

Comment 19

[Sam Schinke]

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

Comment 20

[Boris Zbarsky [:bzbarsky]]

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.

Comment 21

[John Keiser (jkeiser)]

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.

Comment 22

[Sam Schinke]

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

Comment 23

[John Keiser (jkeiser)]

*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.

Comment 24

[Sam Schinke]

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

Comment 25

[Boris Zbarsky [:bzbarsky]]

*** Bug 200587 has been marked as a duplicate of this bug. ***

Comment 26

[Boris Zbarsky [:bzbarsky]]

*** Bug 270620 has been marked as a duplicate of this bug. ***

Comment 27

[Boris Zbarsky [:bzbarsky]]

*** Bug 253704 has been marked as a duplicate of this bug. ***