474893 - List controls should fire a focus event on the selected child when tabbing or when the selected child changes while the list is focused

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[James Teh [:Jamie]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090122 Minefield/3.2a1pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090122 Minefield/3.2a1pre

When one tabs to a multiple selection list created using the <select> HTML element with a "size" greater than 1 or the "multiple" attribute set, a focus event should be fired on the selected child option, rather than just on the list itself. (This should not happen for <select size="1">, as this generates a combo box which must first be expanded.) Note that the selected option does receive the focused state, but no focus event is fired for it.

Reproducible: Always

Steps to Reproduce:
1. Open the attached test case.
2. Tab to the "Select size 3" list.
3. Observe that a focus event was fired on the list. Observe that "Helium" is the active item and has the focused state, but no focus event was fired on it.
4. Tab to the "Select multiple size 3" list.
5. Observe that a focus event was fired on the list. Observe that "dogs" is the active item and has the focused state, but no focus event was fired on it.
Actual Results:  
NO focus event was fired on the "Helium" or "dogs" list items.

Expected Results:  
A focus event should be fired on the "Helium" and "dogs" list items.

This is probably most easily tested with NVDA, although accProbe should show this as well.

Note that if no items are selected in a <select multiple> list, the focused state is always set on the first item, even if, for example, pressing ctrl+downArrow would take you to the third item. However, this is probably a separate bug.

Comment 1

[James Teh [:Jamie]]

Attachment: Test case.

Test case with <select size="3"> and <select multiple size="3"> lists.

Comment 2

[Neil Deakin]

You're confusing 'focused' with 'selected'. Options do not become focused, they become selected. When an option is selected, a change event is fired at the <select> element.

Comment 3

[Neil Deakin]

I just noticed you filed this under accessilbility, so sorry, this may be ok after all.

Comment 4

[Marco Zehe (:MarcoZ)]

Yes, this is a valid bug for accessibility.

Comment 5

[David Bolter [:davidb] (NeedInfo me for attention)]

Just thinking aloud here... html <select> sounds similar to dhtml containers that use aria-activedescendant, where the container always has focus, but we fire a focus event for the child pointed to by the container's aria-activedescendant property. We can maybe do the same for <select>.

Comment 6

[James Teh [:Jamie]]

(In reply to comment #5)
> Just thinking aloud here... html <select> sounds similar to dhtml containers
> that use aria-activedescendant, where the container always has focus, but we
> fire a focus event for the child pointed to by the container's
> aria-activedescendant property. We can maybe do the same for <select>.
This sounds about right. In fact, you can work around this issue by setting aria-activedescendant on the <select> element to the selected option. However, this is obviously not the correct solution for <select> elements.

Comment 7

[James Teh [:Jamie]]

As well as not firing a focus event when tabbing to the list, a focus event is not fired if the selected item changes without user input; e.g. in response to JavaScript code.

Comment 8

[alexander :surkov (:asurkov)]

changing summary to reflect the XUL case

Comment 9

[alexander :surkov (:asurkov)]

fixed by bug 673958

Comment 10

[Marco Zehe (:MarcoZ)]

Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1