380706 - Labels will not be reported while browsing the list item with arrow keys.

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Tim Miao]

Steps to reproduce:
1. Launch firefox and orca.
2. Open firefox preferences dialog, tab focus onto the top tab list.
3. Press Left/Right arrow to move focus among different tab list items.

Expected result:
Label of current list item should be read by orca.

Actual result:
Labels are not reported by orca.

Additional info:
This bug can be found with 20070514 trunk nightly build.
The list item can be reported if browsing with Tab key.

Comment 1

[Tim Miao]

This bug can be reproduced on thunderbird too.

Comment 2

[Aaron Leventhal]

We don't take Orca-specific bugs.

However, if it is a bug in Mozilla, then this is a Core bug, not Firefox-specific (nor SunOS-specific).

What is the actual bug in our a11y hierarchy?

Comment 3

[Joanmarie Diggs]

(In reply to comment #2)
> What is the actual bug in our a11y hierarchy?
 
It seems that we are not getting any events (in particular focus events) for the list items in either of the Preferences dialogs.

Comment 4

[Aaron Leventhal]

Did it ever work?

Comment 5

[Joanmarie Diggs]

(In reply to comment #4)
> Did it ever work?
> 
Yup!  The "winner" seems to be the 4-05 build.  It works through 4-04, from 4-05 on it's broken. 

Comment 6

[Ginn Chen]

I assume  the labels we talked about here are "Main Tabs Content Feeds Privacy Security Advanced".

I noticed some focus events are missing for these list items, but it seems Orca doesn't read the focused listitem w/ or w/o the event.
Gnopernicus works for me with April 3rd's nightly firefox.

Comment 7

[Joanmarie Diggs]

(In reply to comment #6)
> I assume  the labels we talked about here are "Main Tabs Content Feeds Privacy
> Security Advanced".

Yep!

> I noticed some focus events are missing for these list items, but it seems Orca
> doesn't read the focused listitem w/ or w/o the event.

Really?  With the latest Orca, using the left and right arrows to move among those items causes Orca to speak them. If I Tab away from them and then back, Orca also speaks them.   I wonder what we're doing differently....

Comment 8

[Ginn Chen]

I've confirmed it's a regression of Bug 377612.
Sorry for the inconvenient.

Comment 9

[Ginn Chen]

Attachment: patch

prefPane is firing RadioStateChange rather than CheckboxStateChange

Comment 10

[alexander :surkov (:asurkov)]

Comment on attachment 264964 [details] [diff] [review]
patch

Oops, it's my bad. Thank you Ginn for fixing this.

>   if (eventType.EqualsLiteral("RadioStateChange")) {
>     PRUint32 state = State(accessible);
>-    PRBool isEnabled = state & nsIAccessibleStates::STATE_CHECKED;
>+
>+    // prefPane tab is implemented as list items in A11y, so we need to
>+    // check nsIAccessibleStates::STATE_SELECTED also.

Please make this comment more descriptive. It is a cause why I possibly made code wrong. I'd like if comment will point that it's actually a hack for 'prefwindow' binding (http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/preferences.xml#503) that contains rediogroup with 'list' role.

Though the problem seems to be a bit deeper. Why if radiogroup has list role then radio doesn't expose STATE_CHECKED state?


>-    // prefPane tab is implemented as list items in A11y, so we need to
>-    // check nsIAccessibleStates::STATE_SELECTED also.
>-    PRBool isEnabled = (state & (nsIAccessibleStates::STATE_CHECKED |
>-                        nsIAccessibleStates::STATE_SELECTED)) != 0;
>+    PRBool isEnabled = state & nsIAccessibleStates::STATE_CHECKED;

It looks it may broke checkbox listitems (see http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/listbox.xml#958). More should we have special accessible for checkbox listitems?

Comment 11

[Ginn Chen]

(In reply to comment #10)
> Though the problem seems to be a bit deeper. Why if radiogroup has list role
> then radio doesn't expose STATE_CHECKED state?
> 
I think the reason is the panebuttion is exposed as listitem rather than radiobutton.
http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/preferences.xml#1261
nsXULListboxAccessible::GetState won't give you STATE_CHECKED.

> It looks it may broke checkbox listitems (see
> http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/listbox.xml#958).
> More should we have special accessible for checkbox listitems?

I think it's not broken.
Check
http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/listbox.xml#967
http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULSelectAccessible.cpp#183
http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULMenuAccessible.cpp#310

Comment 12

[alexander :surkov (:asurkov)]

(In reply to comment #11)
> (In reply to comment #10)
> > Though the problem seems to be a bit deeper. Why if radiogroup has list role
> > then radio doesn't expose STATE_CHECKED state?
> > 
> I think the reason is the panebuttion is exposed as listitem rather than
> radiobutton.

Ah, correct. So, it's not hack actually because it's in toolkit :) Though I'm not sure it's nice way we do. Now, I'd like to have better comment.

http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/preferences.xml#1261
> nsXULListboxAccessible::GetState won't give you STATE_CHECKED.
> 
> > It looks it may broke checkbox listitems (see
> > http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/listbox.xml#958).
> > More should we have special accessible for checkbox listitems?
> 
> I think it's not broken.
> Check
> http://lxr.mozilla.org/mozilla/source/toolkit/content/widgets/listbox.xml#967
> http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULSelectAccessible.cpp#183
> http://lxr.mozilla.org/seamonkey/source/accessible/src/xul/nsXULMenuAccessible.cpp#310
> 

Ah, I see, thanks.

Comment 13

[alexander :surkov (:asurkov)]

Comment on attachment 264964 [details] [diff] [review]
patch

r=me but if you'll give more descriptive comment then it would be excellent.

Comment 14

[Ginn Chen]

committed with revised comment