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.
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.
Summary: Fire MSAA scrolling_end for anchor jumps, not selection_within → Fire MSAA scrolling_start for anchor jumps, not selection_within
Created attachment 183619 [details] [diff] [review] selection_within -> scrolling_start
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
Attachment #183619 - Flags: review?(timeless) → review+
Comment on attachment 183619 [details] [diff] [review] selection_within -> scrolling_start a=shaver
Attachment #183619 - Flags: approval1.8b3? → approval1.8b3+
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
Status: NEW → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.