234646 - "accesskey" attribute behavior undesirable if the same key is re-used

Status: RESOLVED DUPLICATE of bug 129268

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Ryan Lamansky]

User-Agent:       
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

When an accesskey attribute (for instance, on a form input), is used in multiple
places, Mozilla jumps to the last place it's used.

The desired behavior is to cycle through the objects affected by the key.

The HTML standard does not define the expected behavior in the above scenario,
though the desired solution described above is currently implemented by MSIE
6.0, and is arguably the most useful solution.

Reproducible: Always
Steps to Reproduce:
Create an HTML file.  Include the following in the body:

<input type="text" name="Illustration1" value="Access Key: A" accesskey="a" />
<input type="text" name="Illustration2" value="Access Key: A" accesskey="a" />
<input type="text" name="Illustration3" value="Access Key: B" accesskey="b" />

(The above code is sufficient to illustrate the problem, a complete HTML
document is not needed.)
Actual Results:  
On Windows with Mozilla 1.6, Alt+A selects the second, and Alt+B selects the third.

With MSIE 6.0, Alt+A cycles between the first and second.

Expected Results:  
It should cycle through the elements with the same attribute.

Not a bug per-se, but as MSIE already has a superior implementation (despite not
really being updated in 3 years), Mozilla should do the same.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Note that an accesskey on a button should actually _click_ the button, not just
focus it.  Same for links.  So you're asking for a textfield-specific hack...

Comment 2

[Ryan Lamansky]

(In reply to comment #1)
> Note that an accesskey on a button should actually _click_ the button, not just
> focus it.  Same for links.  So you're asking for a textfield-specific hack...

Not textfield-specific, form input specific.  Radio buttons and checkboxes would
also be affected.  Other accesskey objects should continue to function as before.

Primarily, though, this is for text fields.  The intended usage is for a web
application with a sometimes-long list of people's names, each with a set of
fields associated with the name.  Using the accesskey is a way to quickly move
to a certain place in the list; enhancing it to cycle would be excellant.

Actually, thinking more about this, if this were enhanced beyond what I've
described to take the next item matching the access key after the
currently-focused item, some whole forms could be filled out and submitted just
by holding the Alt key and tapping various letters.

A logical model for this would be something to the effect of:
1. As the document is parsed, make a list of access keys in the order they appear.
2. When the access key is triggered, activate the first item after the currently
focused one, wrapping around to the beginning of the document if the end is reached.

That would be compatible with traditional accesskey usage as well as support my
original scenario and the extension I thought of.

-Ryan

Comment 3

[timeless]

*** This bug has been marked as a duplicate of 129268 ***