Bug 1422674: Fix IAccessible::accChild on parent process accessibles with positive indices. r?MarcoZ
Previously, in the parent process, we were treating positive child ids as remote unique ids.
This of course failed when searching remote documents and returned early.
Make sure we only treat ids as remote if they are less than 0.
Ids above 0 are child indices and are handled later in the code for both local and remote children.
MozReview-Commit-ID: 2KmFj6rTXTV
--- a/accessible/windows/msaa/AccessibleWrap.cpp
+++ b/accessible/windows/msaa/AccessibleWrap.cpp
@@ -1475,17 +1475,20 @@ AccessibleWrap::GetIAccessibleFor(const
return nullptr;
}
// If the MSAA ID is not a chrome id then we already know that we won't
// find it here and should look remotely instead. This handles the case when
// accessible is part of the chrome process and is part of the xul browser
// window and the child id points in the content documents. Thus we need to
// make sure that it is never called on proxies.
- if (XRE_IsParentProcess() && !IsProxy() && !sIDGen.IsChromeID(varChild.lVal)) {
+ // Bug 1422674: We must only handle remote ids here (< 0), not child indices.
+ // Child indices (> 0) are handled below for both local and remote children.
+ if (XRE_IsParentProcess() && !IsProxy() &&
+ varChild.lVal < 0 && !sIDGen.IsChromeID(varChild.lVal)) {
if (!IsRoot()) {
// Bug 1422201: accChild with a remote id is only valid on the root accessible.
// Otherwise, we might return remote accessibles which aren't descendants
// of this accessible. This would confuse clients which use accChild to
// check whether something is a descendant of a document.
return nullptr;
}
return GetRemoteIAccessibleFor(varChild);