302677 - Accessible focus events incorrect for autocomplete

Status: RESOLVED FIXED

(Firefox :: Disability Access, defect)

Description

[Aaron Leventhal]

Using accessibility testing tools, and watching the focus, I observe:

The first down arrow into an autocomplete fires no focus event. Then, after down
arrowing past the end of the list, the list itself receives focus and nothing is
shown selected. The next down arrow starts triggering focus events on the items.

- The items should get focus events right away
- The list itself should never get focus

Comment 1

[Aaron Leventhal]

Attachment: 1) Stop traversing autocomplete list when arrow reaches top or bottom, 2) Okay to fire repeat focus events for DOMMenuItemActive-based focuses

Comment 2

[[e-mail]]

Comment on attachment 191206 [details] [diff] [review]
1) Stop traversing autocomplete list when arrow reaches top or bottom, 2) Okay to fire repeat focus events for DOMMenuItemActive-based focuses

>-            this.selectedIndex = this.getNextIndex(aReverse, amount, this.selectedIndex, this.tree.view.rowCount-1);
As far as I know, this behaviour is by design. Even IE does it.

>+                                  PRBool aDupeFocusEventsOk = PR_FALSE);
I would have just called it aForceEvent

>   aAccessible->GetFinalRole(&role);
Do you still use the role? You removed a condition that uses it.

>     // Only fire focus event for DOMMenuItemActive is not inside collapsed popup
>     if (0 == (containerState & STATE_COLLAPSED)) {
>-      FireAccessibleFocusEvent(accessible, targetNode);
>+      FireAccessibleFocusEvent(accessible, targetNode, PR_TRUE);
Are you expecting multiple focus events for real menuitems?

Comment 3

[Aaron Leventhal]

Attachment: 1) Allow arrow off of list back into URL bar, 2) Change param name to aForceEvent, 3) Move GetFinalRole(&role) right before role is used

Comment 4

[Aaron Leventhal]

Neil, I addressed your parameter name change, and the arrow key behavior. The
role variable was still needed.

Multiple focuses could happen for an menu/list/tree item that uses
DOMMenuItemActive if the user is at the end of the choices and hits down arrow,
if the widget doesn't cycle.

Comment 5

[[e-mail]]

Comment on attachment 191304 [details] [diff] [review]
1) Allow arrow off of list back into URL bar, 2) Change param name to aForceEvent, 3) Move GetFinalRole(&role) right before role is used

OK, so you can have r+sr on nsRootAccessible but I'm not convinced on the
autocomplete change, please get a toolkit user peer to double-check edge cases.

Comment 6

[Aaron Leventhal]

Comment on attachment 191304 [details] [diff] [review]
1) Allow arrow off of list back into URL bar, 2) Change param name to aForceEvent, 3) Move GetFinalRole(&role) right before role is used

Mike, I need r= only on the autocomplete.xml change

Comment 7

[Aaron Leventhal]

Checking in toolkit/content/widgets/autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v  <--  autocomplete.xml
new revision: 1.42; previous revision: 1.41
done
Checking in accessible/src/base/nsRootAccessible.h;
/cvsroot/mozilla/accessible/src/base/nsRootAccessible.h,v  <--  nsRootAccessible.h
new revision: 1.50; previous revision: 1.49
done
Checking in accessible/src/base/nsRootAccessible.cpp;
/cvsroot/mozilla/accessible/src/base/nsRootAccessible.cpp,v  <-- 
nsRootAccessible.cpp
new revision: 1.128; previous revision: 1.127
done

Comment 8

[Ed Lee :Mardak]

With this fix, pressing down at the last autocomplete selection causes that
value to go into the location bar (same with pressing up from the first
selection). This closes autocomplete when the user might want to continue with
the autocomplete.

If I type "b", bugzilla entries appear and I can press down to select them. But
if I want to go back up to the location bar to add an "o" for bonsai, it'll
select the first item and autocomplete will treat that whole selectin as the
base for the autocomplete instead.

Comment 9

[Aaron Leventhal]

(In reply to comment #8)
> With this fix, pressing down at the last autocomplete selection causes that
> value to go into the location bar (same with pressing up from the first
> selection). This closes autocomplete when the user might want to continue with
> the autocomplete.
> 
It causes bug 303928, which currently speficies Tab and should probably mention
down arrow.