The default bug view has changed. See this FAQ.

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

VERIFIED FIXED in mozilla10

Status

()

Core
Disability Access APIs
VERIFIED FIXED
8 years ago
6 years ago

People

(Reporter: Jamie, Assigned: surkov)

Tracking

({access})

Trunk
mozilla10
x86
Windows XP
access
Points:
---
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
Keywords: access
Version: unspecified → Trunk
(Reporter)

Comment 1

8 years ago
Created attachment 358315 [details]
Test case.

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

Comment 2

8 years ago
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → INVALID

Comment 3

8 years ago
I just noticed you filed this under accessilbility, so sorry, this may be ok after all.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---

Comment 4

8 years ago
Yes, this is a valid bug for accessibility.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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>.
(Reporter)

Comment 6

8 years ago
(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.
(Reporter)

Comment 7

8 years ago
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.
Summary: When tabbing, HTML <select> lists should fire a focus event on the selected child → HTML <select> lists should fire a focus event on the selected child when tabbing or when the selected child changes while the list is focused
(Assignee)

Updated

6 years ago
Depends on: 673958
Flags: in-testsuite?
(Assignee)

Comment 8

6 years ago
changing summary to reflect the XUL case
Summary: HTML <select> lists should fire a focus event on the selected child when tabbing or when the selected child changes while the list is focused → List controls should fire a focus event on the selected child when tabbing or when the selected child changes while the list is focused
(Assignee)

Comment 9

6 years ago
fixed by bug 673958
Assignee: nobody → surkov.alexander
Status: NEW → RESOLVED
Last Resolved: 8 years ago6 years ago
Flags: in-testsuite? → in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla10
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.