220390 - ACCESSKEY incorrectly supported on multiline SELECT tag

Status: RESOLVED FIXED

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

Description

[Daniel Faber]

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

mozilla doesn't support the accesskey-attribute in a <select>-element if this
<select>-element is single line.

<select size="3" accesskey="e"> works as expected, the <select>-element get the
focus

<select size="1" accesskey="e"> does not work

Reproducible: Always

Steps to Reproduce:
1. visit http://www.fsi.uni-tuebingen.de/users/faber/bugs/mozilla2.html
2. try the shortcuts alt+a, alt+b, alt+c, alt+d, alt+e, alt+f
Actual Results:  
shortcuts alt+a, alt+b, alt+c, alt+d, alt+f work correctly
alt+e opens the edit-menu.
please notice that alt+b don't open the bookmark-menu but jumps to the
<input>-element as it shoult do

Expected Results:  
alt+e shoult jump to the <select>-element

I found this bug in Mozilla 1.4 and 1.5rc1

I know that the accesskey-attribute is not allowed in the <select>-element in
XHTML 1.0 at all, but it works for multi-line <select>-elements an so it should
work single-line <select>-elements, too.

I found a workaround:  Use a <label>-element assosiated with the single-line
<select>-element and put the accesskey-attribute to the <label>-element. (visit
http://www.fsi.uni-tuebingen.de/users/faber/bugs/mozilla2.html and press alt+f
for a little demo)

Comment 1

[Bill Mason]

ACCESSKEY is not a valid attribute for SELECT.  See
http://www.w3.org/TR/html401/interact/forms.html#h-17.6 and
http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey

So actually the bug here is that ACCESSKEY works at all on a multiline SELECT
element.

->Keyboard Navigation

Comment 2

[Nian Liu(n/a in a long time)]

Attachment: patch for 220390

according to w3c, accesskey only support element A, AREA, BUTTON, INPUT, LABEL,
and LEGEND, and TEXTAREA.

Comment 3

[Aaron Leventhal]

It looks to me like you're fixing different bugs:
adding accesskey support for area and anchor elements.

Also, legend element is apparently broken. Patch in bug 81481

There were bugs for the other missing parts, but I can't find them right now.

We should be fixing the bug that's listed here.

Comment 4

[Nian Liu(n/a in a long time)]

bug here is that accesskey attribute is working for select element. pls. refer
to Bill Mason's comment. the reason is that once register the accesskey, code
should first see whether the accesskey attribute is supported by the element
type. instead of that, previous code just get the accessky value directly.
that's the reason why multiple line select element supports accesskey. to add
area and anchor support is just to keep consistence with the w3c standard.

Comment 5

[Aaron Leventhal]

With your patch does the accesskey still work on a label attached to a <select>?

Or does the W3C specify that a label cannot apply to a <select>?

Comment 6

[Nian Liu(n/a in a long time)]

for your first question. yes, sure it works. it has been well tested based on
test case.

for your second question. i haven't seen such limitation on w3c.

Comment 7

[Johnny Stenback (:jst)]

I'm hesitant to sr this change. IE supports accesskey on selects, any reason
(beyond the spec) that we shouldn't?

Comment 8

[Nian Liu(n/a in a long time)]

then i think what we met is that either make accesskey work for select(both
single and multi), or make it not work for neither. 

jst, could you make a decision then i can fix this bug based on that?

Comment 9

[Johnny Stenback (:jst)]

Ok. I'd say that we follow IE here and make it work for both milti and single
line selects then.

Comment 10

[Nian Liu(n/a in a long time)]

Attachment: patch for 220390

the reason why accesskey in select element works for multiple line and not for
single line is that accesskey will only be registered when multiple line.

Comment 11

[Aaron Leventhal]

Comment on attachment 147972 [details] [diff] [review]
patch for 220390

Looking in CVS blame, this code was originally checked in with the follwoing
comment:
480 rods       1.155 // for Bug 47302 (remove this comment later)

http://bugzilla.mozilla.org/show_bug.cgi?id=47402

I'm not sure exactly why rods added that IsInDropDownMode() requirement, but
I'm uncomfortable giving r= unless we at least address the issue.

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 147972 [details] [diff] [review]
patch for 220390

If this works, I'm happy to take this change and it looks like that assertion
is gone now, so I doubt that old comment is much to worry about.

Comment 13

[Nian Liu(n/a in a long time)]

Attachment: patch for 220390

in fact, this code was originally checked in in 1.120. in 1.155 rods move
unregister accesskey from destructor to Destroy() and add a precondition "not
drop down". to make reg/unreg as a pair, i modified Destroy() to remove the
precondition "not drop down". this pacth didn't break any test case mentioned
in 1.120. however, it's still not clear why rods add a precondition "not drop
down" in 1.120

Comment 14

[Aaron Leventhal]

Neo, is this patch going to go in or not?

Comment 15

[Nian Liu(n/a in a long time)]

Aaron, patch is checked in on 06/11 by Robin Lu

Comment 16

[Aaron Leventhal]

Nian, any reason this bug wasn't marked FIXED?

Comment 17

[Nian Liu(n/a in a long time)]

Aaron, the reason is that i'm quite new here and don't famillar with whole
process.^_^ 

thanks for your reminder. i'll do that better in coming days.