GNOME Bugzilla – Bug 480021
Need to handle list items in whereAmI and better address XUL list items
Last modified: 2007-10-03 04:25:15 UTC
While working on the XUL widget tests, I discovered a couple of things: 1. where_am_I.py doesn't have handling specific to list items. 2. XUL items with ROLE_TREE (as opposed to ROLE_TREE_TABLE) have a child of ROLE_LIST. Other than that, they seem to work much like tree tables. These should be passed off to the default speech generator rather than handled within Gecko. When I tried to hand the XUL list items off to the default generator, I discovered a third thing: The _getSpeechForListItem() which was added to provide handling for ARIA trees (see bug 462156) causes the level to be spoken for *each* list item. Everywhere else in Orca we only speak the level when it has changed. Patch to follow.
Created attachment 96145 [details] [review] proposed patch Adds handling to where_am_i.py Sends XUL list items off to speechgenerator.py Removes the node level speaking from speechgenerator.py so that we only speak the level when it has changed. Caught a silly, and up to this point irrelevant, mistake in default.getChildNodes(): Up to this point, all we cared about in getChildNodes was the child count, which was correct. Now we care about the actual objects. We were appending the target rather than the child. Oops. I tested this with the bookmarks manager in the panel on the left (the panel on the right is a proper tree table), along with various other places where we get item counts and deal with list items. It seems correct with one exception: In the ARIA and Dojo widgets, speaking the level *all the time* meant that we were speaking it when we first entered the list/tree. When I remove that, we speak the level appropriately (i.e. only when it changes) BUT not when we first enter the list/tree. Perhaps something is causing us to not call default.locusOfFocusChanged() in that instance?? I'm not sure as I haven't debugged it further. Assuming this patch is what we want to do, I'll leave that to Scott. :-) Mike please test.
Looks good with the exception of first entering the list.
So.... What do we want to do here? Scott any suggestions?
Something has changed in Firefox and we are no longer getting ARIA related object attributes for some ARIA widgets, trees in particular. I do not see this problem on an older version of Firefox (9-16). See https://bugzilla.mozilla.org/show_bug.cgi?id=398156 for details on the missing object attributes for ARIA widgets.
Strange. I now see the problem after closing the page and then reopening it. I will test further.
Created attachment 96474 [details] [review] second version of Need to handle list items in whereAmI ... This is a good one. It is almost a miracle that we had a test case to illustrate it. The problem is that the dojo tree test case has a heading at level=1. As you navigate to the tree, you encounter a list item at level 1 in the tree. However, we don't repeat announcements when the level has not changed. The fix is to exclude headings in Gecko.getNodeLevel() because there is a special method for headings for this task. Questions: Are there any other object types that may need to be excluded here? Is this the best (most generic) way of tackling this problem?
Not sure if it's the best way, but it seems to work. :-) Maybe Will has some thoughts on this?
(In reply to comment #7) > Not sure if it's the best way, but it seems to work. :-) > > Maybe Will has some thoughts on this? I can't think of a better way. The only thing I noticed in the patch while looking at it is what seems to be a subtle change in the output. Instead of "level %d", it seems to be saying "tree level %d". If that's the case, was the change intentional and is this something that's Mike approved?
The reason for the output change is that Joanie explained that these lists actually contain trees and also allow the same actions for expanding and collapsing.
Thanks for the explanation. The "tree level" string translation is not new, which is good and means we can apply this change (or one similar to it) to gnome-2-20. Scott, Joanie: how comfortable are you with making this patch a candidate for gnome-2-20?
Yup, we've got a hierarchy of: - Tree - List - List Item As opposed to something like - Tree Table - Table Cell It seems that in XUL, a single column table is a Tree and a multi-column table is a Tree Table.
> Scott, Joanie: how comfortable are you with making this patch a candidate for > gnome-2-20? I'm good with it.
OK - please commit to both trunk and gnome-2-20. If the patch for gnome-2-20 ends up being different due to differences in the rest of the code, please add it here. Thanks!
Created attachment 96492 [details] [review] patch for the 2-20 branch
Patches committed. Moving to [pending]. Scott, thanks again!
This one seems to be working correctly
Thanks Mike. Closing as FIXED.