Last Comment Bug 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
: List controls should fire a focus event on the selected child when tabbing or...
Status: VERIFIED FIXED
: access
Product: Core
Classification: Components
Component: Disability Access APIs (show other bugs)
: Trunk
: x86 Windows XP
: -- normal (vote)
: mozilla10
Assigned To: alexander :surkov
:
Mentors:
Depends on: 673958
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-22 18:31 PST by James Teh [:Jamie]
Modified: 2011-09-29 08:09 PDT (History)
6 users (show)
surkov.alexander: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case. (675 bytes, text/html)
2009-01-22 18:36 PST, James Teh [:Jamie]
no flags Details

Description James Teh [:Jamie] 2009-01-22 18:31:34 PST
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] 2009-01-22 18:36:25 PST
Created attachment 358315 [details]
Test case.

Test case with <select size="3"> and <select multiple size="3"> lists.
Comment 2 Neil Deakin 2009-01-23 06:23:19 PST
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 2009-01-23 06:24:53 PST
I just noticed you filed this under accessilbility, so sorry, this may be ok after all.
Comment 4 Marco Zehe (:MarcoZ) 2009-01-23 06:31:00 PST
Yes, this is a valid bug for accessibility.
Comment 5 David Bolter [:davidb] 2009-01-23 06:47:11 PST
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] 2009-01-30 16:56:50 PST
(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] 2009-01-30 17:00:50 PST
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 2011-09-08 03:08:19 PDT
changing summary to reflect the XUL case
Comment 9 alexander :surkov 2011-09-28 02:22:06 PDT
fixed by bug 673958
Comment 10 Marco Zehe (:MarcoZ) 2011-09-29 08:09:02 PDT
Verified fixed in Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a1) Gecko/20110929 Firefox/10.0a1

Note You need to log in before you can comment on or make changes to this bug.