102057 - Need default visual indicator for submit button used when hitting return.[form sub]

Status: NEW

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Description

[kinmoz]

This is an offshoot from bug 99920.

When focus is placed in a textfield, the first submit button in the form should
be given a visual indicator that tells the user that it (the submit button) will
be used when/if they hit the return key in the textfield.

Comment 1

[Tim Powell]

Is this a duplicate of or blocker for bug 63728? Initial discussion in that bug 
described IE's default submit button behavior, which I'd never noticed :-( and 
seemed to be suggesting that it needed to be implemented in Mozilla. The bug 
seems to have lost focus from there.

Comment 2

[Matthew T (active 1999-2002)]

Yes.

Comment 3

[rods (gone)]

reassinging to new owner of form submission

Comment 4

[Alexandru Savulov]

not form submission, sorry

Comment 5

[Aaron Leventhal]

This should be part of the new XBL form controls.

Comment 6

[Matthew T (active 1999-2002)]

Actually, I'm not sure this bug is valid. When a form is submitted with the
Enter key, it's submitted with *no* particular button. (This is how Google knows
whether to advise you that you can just press Enter instead of clicking the
button -- if you clicked the button, there's an extra parameter in the GET
request). So if we put a default border around a particular button, we'd be
being misleading.

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Julian Fitzell]

Can anyone confirm what the actual status on this issue is?  There seem to be
several bugs all linked to each other, some closed, some arguing both sides of
this issue, etc.

It seems to me that:
a) IE does not consider any button "successful" when you press enter and
therefore doesn't submit any button name
b) the user has not clicked a button so telling the form processor that they did
is misleading
c) we have no way of knowing which button the page designer would like to be the
default
d) we give the user no indication of which button is default
e) by submitting without a button, we allow the web page designer to simply
redraw the form, therefore allowing them to decide what the default action should be
f) the HTML spec does not require a button to be submitted.  It states that "If
a form contains more than one submit button, only the activated submit button is
successful", but does not indicate that "1 or more" buttons must be submitted,
merely that "no more than 1" may be submitted.

Based on all this, I believe the correct behaviour is to submit the form without
including any button-press information.  This has always seemed to be the
standard behaviour in all other browsers I have tried, but I would be interested
to hear if people have other examples that behave in the current fashion
(submitting the first button on the form).

Comment 9

[John Keiser (jkeiser)]

IE submits by clicking buttons when you press enter in many cases.  We do it in
several more, but that's not the issue here.  See
http://bugzilla.mozilla.org/attachment.cgi?id=64974&action=view for a set of
testcases, some of which has onclick fired on the submit button in IE.

The thing we need for this is a selector like :active-button.  I don't see it as
terribly important, though.

Comment 10

[Daniel Wang]

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

Comment 11

[bmay]

Attachment: On <enter> in the text field the form submits using the first button

I want the value of Action to be "view" when <return> is hit in the text area,
as I would expect because the default value of Action = "view". Instead the
form arbitrarily "clicks" on the first button in the page setting Action =
"new".

Comment 12

[bmay]

I meant to add that I agree with Julian Fitzell's excellent assessment of the bug.

Comment 13

[John Keiser (jkeiser)]

That is not this bug, and has been discussed ad nauseum elsewhere.  See bug
156683 and *try out* attachment 64974 [details], which I linked to earlier.  Then comment
there or file a new bug if you still feel something is wrong that is different
from bug 156683.

This bug is about making the default submit button show activated, and *only*
about that.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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

Comment 15

[Foteos Macrides]

(In reply to comment #0)
> When focus is placed in a textfield, the first submit button in the form
> should be given a visual indicator that tells the user that it (the submit
> button) will be used when/if they hit the return key in the textfield.

Note that IE and Opera on Windows add a darker border to the "first" submit
button (i.e., the 1st that was encountered when parsing a form block's content)
not only when input elements with type="text" receive focus via keyboard
navigation in the rendered display, but also for the other input types such as
check boxes and radio buttons which do not cause form submission when the return
or enter key is hit.  The exception is reset buttons, which take the darker
border from the submit button unto themselves when receiving focus.

Also, when textareas or select boxes in the form block's content receive focus,
the "first" select button gets a darker border (and the return key does not
cause a submission for these, either).

When a form block's content contains more than one submit button, these
behaviors do help to indicate which submit button will be treated as having been
activated when focus is on an element for which hitting the return key causes
activation (submission of the form), and in that sense help to indicate the
"default" submit button.

But equally important is that when a document has multiple forms (and most
commonly one submit button per form), these behaviors yield an indication of
which submit button belongs to the "current" form (i.e., in which some element
has focus, whether or not pressing return or enter will cause a submission when
that element has focus).

I'm not quibbling about semantics, but simply am anxious that this bug be fixed
in a manner which yields behavior in the Geckos which is fully equivalent to
that in IE and Opera, so that it will be easer to write documents which are
maximally friendly to keyboard navigation at sites which seek to be ADA-compliant.

This is a testcase that I am using to check across-browser behaviors in relation
to this bug:

http://www.macridesweb.com/oltest/hide.html

Comment 16

[Aaron Leventhal]

Changing summary, because the darkened border does not only show up when a
textfield has focus.