294222 - Fire MSAA scrolling_start for anchor jumps, not selection_within

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

We're going to be using selection_within for what it was originally intended for
-- it gets fired on widgets capable of multiple selection when the selection
within it changes.

This bug is to use the MSAA scrolling_end event as our anchor jump indication.

Comment 1

[Aaron Leventhal]

Actually it will be better to use scrolling_start, so that we don't have dual
meanings for scrolling_end. Right now we're using scrolling_end for any kind of
scroll occurance.

Comment 2

[Aaron Leventhal]

Attachment: selection_within -> scrolling_start

Comment 3

[timeless]

Comment on attachment 183619 [details] [diff] [review]
selection_within -> scrolling_start

>Index: accessible/src/msaa/nsDocAccessibleWrap.cpp
>@@ -278,11 +278,11 @@ nsDocAccessibleWrap::GetFirstLeafAccessi
>+  // Fire SCROLLING_START on first leaf accessible -- because some
>   // assistive technologies only cache the child numbers for leaf accessibles
>   // the can only relate events back to their internal model if it's a leaf.
they? :)
>   // There is usually an accessible for the focus node, but if it's an empty text node
>   // we have to move forward in the document to get one

Comment 4

[Mike Shaver (:shaver emeritus)]

Comment on attachment 183619 [details] [diff] [review]
selection_within -> scrolling_start

a=shaver

Comment 5

[Aaron Leventhal]

Checking in accessible/src/msaa/nsDocAccessibleWrap.cpp;
/cvsroot/mozilla/accessible/src/msaa/nsDocAccessibleWrap.cpp,v  <-- 
nsDocAccessibleWrap.cpp
new revision: 1.27; previous revision: 1.26
done