Consider the page http://www.mozilla.org/access/unix/new-atk.html. Let acc be the accessible for the page's html container which has 21 children. The following at-spi calls return odd results: (Pdb) acc.getChildAtIndex(0).getIndexInParent() 0 (Pdb) acc.getChildAtIndex(1).getIndexInParent() 1 (Pdb) acc.getChildAtIndex(2).getIndexInParent() 2 (Pdb) acc.getChildAtIndex(3).getIndexInParent() 3 (Pdb) acc.getChildAtIndex(4).getIndexInParent() 5 (Pdb) acc.getChildAtIndex(5).getIndexInParent() 8 (Pdb) acc.getChildAtIndex(6).getIndexInParent() 17 ... The getIndexInParent return value does not match the index of the child as it is known to the parent. At first, I thought it might have been counting chunks of text between embeds in the child count. But that doesn't fully explain the large gaps between children 5 and 6. Maybe it's also counting descendants? If so, it is undesirable. Since there is no concept of prev/next in at-spi like there in other a11y APIs, ATs have to rely on accurate getIndexInParent values to determine next/previous within a level of the accessible hierarchy.
Created attachment 233034 [details] [diff] [review] Don't count text or whitespace objects At the very least it *is* counting text/whitespace objects and it should not be. So we need this fix either way. Let's get this in and see if it fixes the problem.
Why do we patch nsAccessibleWrap.cpp but not nsAccessible.cpp?
(In reply to comment #2) > Why do we patch nsAccessibleWrap.cpp but not nsAccessible.cpp? Because in both nsIAccessible and IAccessible we do have the ROLE_TEXT_LEAF children exposed. It's only in ATK where we hide those and only expose that text via nsIAccessibleText in the parent.
Comment on attachment 233034 [details] [diff] [review] Don't count text or whitespace objects sorry for the late, please add a comment to explain the difference between getIndexInParentCB and nsAccessible::GetIndexInParent