GNOME Bugzilla – Bug 520297
"Dead" accessibles in Gecko interfere with Orca's caret navigation and structural navigation
Last modified: 2011-02-19 15:53:03 UTC
Please describe the problem: I found this on a particular site, so that it may be webpage specific. go to: http://www.sueddeutsche.de/app/service/rss/tt/tt.xml Open any story, and type "h" the first time. You will land on the first heading of the story. Retyping "h" cycles you first through the headings related to that story. Going on brings you to the headings of the department, responsable for the article. When you keep on cycling, you always cycle through the headings, related to the department, but you will never get back to the starting heading of the chosen story. Note: Reviewing the site with other screen readers indicates that it is rather complicated in its structure. So it may be a site specific issue, but, on the other hand, there may be similar phenomena on other pages. Steps to reproduce: 1. Open FF3 2. Open: http://www.sueddeutsche.de/app/service/rss/tt/tt.xml 3. Choose a story and open it. Do the steps described above. Actual results: Expected results: You cycle through only a part of the heading, the ones related to the department. Does this happen every time? It happens all the time. Other information: I don't know whether this is specific to one Orca version, because I came upon it, when testing the speed of the latest Orca. So it may be an old problem. Usually I don't cycle through all elements of a page, just for fun.
It is an old problem I believe. I've just needed a good test case. I'll take a look soon. Thanks!
Still investigating, but if I use the UIUC accessibility extension to remove the page's CSS, suddenly we do the right thing. Question is, what CSS is messing us up?
Here's a riddle to entertain you while I work on a fix: What do you get if you cross a <br> floating in space with {display:block; overflow:hidden;}? Give up? A dead accessible. :-( I filed this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=420993 In terms of the fix: I was able to solve the problem for the non-collections code by adding a method to get a count of an object's valid children and using it in findNextObject() instead of relying upon the reported childCount when looking for siblings. I don't yet know how to solve it for the collections code because that's not something I'm familiar with (yet). But that's next on tonight's agenda (after dinner). Stay tuned. :-)
Created attachment 106600 [details] test case 1 (another test case and commentary to follow)
Created attachment 106601 [details] test case 2 (commentary to follow)
I'm playing around with collections in Accerciser's iPython console. I'm starting to grok it.... The difference between test case 1 and test case 2 is a <br> floating about in outer space within a table. (It's present in test case 1; absent in test case 2). Its presence in test case 1 is (combined with the CSS) the source of the dead accessible. Now.... In playing around with the two test cases and collections in general, one of the things I tried was this: 1. queried the collection interface for the document frame 2. created a rule to find objects of ROLE_HEADING 3. used getMatchesFrom() to get the next 10 matches using that rule: a. From the document frame (i.e. the beginning of the document) b. From the last heading in the document For both test cases, 3a resulted in a list of 6 accessibles, all of ROLE_HEADING (there are only 6 headings in each document). For test case 2 (no dead accessibles), 3b resulted in an empty list which seems logical: There aren't any more headings after the last heading. For test case 1, however, 3b resulted in a list of four headings -- the headings which immediately follow the dead accessible. As a result, we don't come to the conclusion that we've run out of headings, need to wrap (including making the wrapping announcement) and start from the top. Instead, we happily assume that, lo and behold!, we've found another heading and move there. This is what seems to be taking place with the site Hermann mentioned. Now for the questions/observations/thinking out loud: 1. Whose bug is this really? The dead accessible belongs, I assume, to Firefox (already filed). But which app or implementation is responsible for giving us the four headings when it should be giving us an empty list? I'll also ask this on the FF bug I filed. 2. I still think we should do some defensive work here and resolve the problem. If we can check for bogus children, I would think we could check for bogus returned collection values. :-) I'm still debating how. Suggestions welcome. In the meantime, and possibly related to a solution: 3. Looking at what we've implemented, each time we want to get the next object of ROLE_FOO, we get the document frame, then we query its collection interface, then we create a rule, then we ask for the next object according to that rule, then we free the rule we've made. Rinse and repeat. If a user plans to press H just once, this makes perfect sense. But if a user presses H several times to jump down to several headings, should we still be rinsing and repeating? Would it instead make more sense performance-wize to shampoo once really, really well (i.e. ask for all the headings on the page -- maybe do a cap given huge page with a bazillion and one objects).** That way, when the user presses H a second time, we already have his/her heading waiting and just need to move the caret there? And we'd already have the previous ones lined up. Yeah, yeah, yeah, I know, "Joanie, why don't you do some performance profiling and find out?" ;-) I'm happy to. Just wondering if this has been a bridge that was already crossed and dismissed, or if it's worth pursuing with profiling. ** If we do go this route, we'd of course need to be on the look out for shiny javascript miracles in the form of text inserted or deleted by "system" (rather than by user) and children changed events.
(In reply to comment #6) > 1. queried the collection interface for the document frame > 2. created a rule to find objects of ROLE_HEADING > 3. used getMatchesFrom() to get the next 10 matches using that rule: > a. From the document frame (i.e. the beginning of the document) > b. From the last heading in the document ... > For test case 1, however, 3b resulted in a list of four headings -- the > headings which immediately follow the dead accessible. Well...that's not good. > 1. Whose bug is this really? The dead accessible belongs, I assume, > to Firefox (already filed). But which app or implementation is > responsible for giving us the four headings when it should be > giving us an empty list? I'll also ask this on the FF bug I filed. My opinion is that Collections are a performance enhancement -- they basically do in the application process what we could accomplish via normal iterative AT-SPI calls. As such, if normal iterative AT-SPI calls work, but the Collections calls don't, then it's probably a Collections bug. If neither work, it is probably an application or AT-SPI implementation bug. Having said that, if there is some generic defensive code that can be put in place to make the iterative code work, then maybe that might be something to try to put in the Collections implementation. > once, this makes perfect sense. But if a user presses H several > times to jump down to several headings, should we still be rinsing > and repeating? Would it instead make more sense performance-wize > to shampoo once really, really well (i.e. ask for all the headings > on the page -- maybe do a cap given huge page with a bazillion and > one objects).** It may indeed make sense to try to optimize this somehow if it's determined that this is indeed a performance problem. It might not be, but measurement can tell.
I've given this some more thought. If we have to check all children of an object just to see if they're valid, that's a performance hit for objects with lots of children. We shouldn't have the dead accessibles, we shouldn't have to hack around the dead accessibles. I've added a comment to the Mozilla bug (https://bugzilla.mozilla.org/show_bug.cgi?id=420993) I'm blocking this bug against that one. If FF3 is released and the dead accessible problem persists, we can hack.
For another example of the issue, see bug 523226: Orca should not get stuck while browsing the FAQ at slimdevices.com.
*** Bug 523226 has been marked as a duplicate of this bug. ***
The blocking mozilla bug was fixed in october 2010. So I'm unblocking unless someone can reproduce that bug. Is there anything else we need to do or can this bug be closed too?
Since nobody has mentioned other work that needs to be done I'm closing this bug. If there's something that still needs to be fixed please reopen.