GNOME Bugzilla – Bug 571058
(ARIA) Orca's caret navigation is kicking in when it shouldn't be
Last modified: 2009-02-24 21:15:56 UTC
Steps to reproduce: 1. Load http://test.cita.uiuc.edu/aria/slider/view_inline.php?title=Slider%20Example%201&ginc=includes/slider1_inline.inc&gcss=css/slider1.css&gjs=../js/globals.js,../js/widgets_inline.js,js/slider1_inline.js (yeah, I know. It's not my fault.) 2. Tab to the sliders. 3. Use the arrow keys to change their value Expected results: It would work. Actual results: Our caret navigation kicks in. Turns out we're getting a bogus caret-moved event for the parent embedded component and setting the locusOfFocus to it as a result. We shouldn't do this. I have a patch but I need to regression test it first.
Renaming/broadening the summary as the fix for this big seems to address a number of others.
Created attachment 128325 [details] [review] fix This (small) patch fixes the UIUC slider, is pylinted, and is regression tested. In addition, it fixes a number of other bugs in the process. Therefore, I've gone ahead and checked it into trunk. Will please review for the gnome-2-24 branch. In the meantime, I'll go through our other bugs, verify those that are fixed, and create new regression tests for them.
Nice. Looks good for gnome-2-24, too. Thanks!
*** Bug 570565 has been marked as a duplicate of this bug. ***
*** Bug 570569 has been marked as a duplicate of this bug. ***
Created attachment 128417 [details] [review] another tweak As discussed in team meeting today, this patch introduces another tweak to isNavigableAria: We will assume it is navigable (i.e. Orca commands should kick in) if it is not focusable (i.e. it's text in a panel). If it is focusable, we will assume it is *not* navigable (i.e. Firefox and/or widget commands should handle it). Committed to trunk; not yet to the gnome-2-24 branch. This stuff is still a work in progress....
*** Bug 571339 has been marked as a duplicate of this bug. ***
*** Bug 570566 has been marked as a duplicate of this bug. ***
Created attachment 128515 [details] [review] more work Another little patch towards the uber bug this is. :-) This addresses the two most recent dups along with a minor issue Will pointed out to me via phone with a dojo toggle button (braille cursor was jumping from position 1 to 0). Patch is PARCed (Pylinted and Regression tested, Committed). ;-) But only to trunk. I'll let it (and the other patches attached to this bug) simmer before committing to the gnome-2.24 branch.
Created attachment 128531 [details] [review] yet another tweak I have never understood why isNavigableAria gets the attributes of the locusOfFocus rather than that of the argument obj. Granted most of the time these two objects are the same, but they don't have to be.... PARCed (trunk only).
*** Bug 570564 has been marked as a duplicate of this bug. ***
Created attachment 128688 [details] [review] combined patches for the gnome-2-24 branch In the interest of clarity, this is the combination of the four patches that I had committed to trunk. This combined patch has just been committed to the gnome-2-24 branch.
Created attachment 128693 [details] [review] bigger change This is a more significant patch which does 3 things that result in more accurate lines and far less chattiness for ARIA widgets. 1. Modifies isNavigableAria to consider the parent's xml-roles attribute if the object under consideration lacks that attribute. It also adds ROLE_SECTION into the things we assume are navigable. 2. Modifies onCaretMoved so that we don't have to do a bunch of checking. If the event source is not navigable ARIA (i.e. it's a widget rather than a text object), it shouldn't be giving us caret-moved events as a general rule. I think that we're triggering some of them by our caret navigation (grabbing focus, trying to set the caret position via the accessible text interface, etc.). Therefore, we only ignore these events if we're controlling the caret. 3. Modifies getLineContentsAtOffset in a significant (but safe) way: If we're not in navigable aria, we're on a button or a page tab or something like that. In that case, don't do our normal process to get the line contents; instead get all the siblings on this line AND don't get any strings for them even if they implement accessible text (which buttons, page tabs, etc. do). This change accomplishes 3 things for sure, and I suspect one other thing. It definitely: 1. Eliminates garbage we were picking up when using find{Next,Previous}Object when building up the line. We were sometimes finding whitespace objects in between our widgets. 2. Makes it easy to place the responsibility of presenting these objects on the appropriate generators: If there's no string, we turn to the generators. 3. Allows us to more easily tailor when we present a full line and when we don't. (e.g. do for page tabs; don't for sliders). It theoretically should also be more performant. Before, for each and every line, we were doing tons of checking for each object on the line to see if it happened to be navigable ARIA. There's no need to do that now because the ARIA line building up is handled independently. I need to run some performance analysis to verify this, but logically the elimination of a bunch of checks is a good thing for performance. ;-) I've committed this to trunk. I've still got some tweaking to do, but I wanted to get this change in for testing in the meantime.