Querying a handle's name can hang forever in some cases.
I'm hoping (albeit doubtfully) that GetNamedPipeServerProcessId might not hang where querying the handle's name does, and also that the handle that's hanging isn't the handle we need.
This seems to fix the problem for one user, so maybe my doubts are unfounded.
Differential Revision: https://phabricator.services.mozilla.com/D197035
This is needed in order to support find in page on Android using remote caret events instead of virtual cursor change events.
Depends on D192641
Differential Revision: https://phabricator.services.mozilla.com/D192642
This is needed in order to support find in page on Android using remote caret events instead of virtual cursor change events.
Depends on D192641
Differential Revision: https://phabricator.services.mozilla.com/D192642
RelationType.h will soon be generated, but it will be generated within the obj dir, so local includes won't work.
Our C++ style guide says we should prefer exported includes wherever possible anyway.
This was done with this shell command inside the accessible/ directory:
```
sed -i 's,#include "RelationType.h",#include "mozilla/a11y/RelationType.h",' `git grep -l '#include "RelationType.h"'`
```
Differential Revision: https://phabricator.services.mozilla.com/D193001
This is necessary to work around a bug in the Windows UI Automation -> IAccessible2 proxy.
See the code comments for details.
Differential Revision: https://phabricator.services.mozilla.com/D187529
Starting with Windows 11 22H2, Microsoft has made internal changes in
msctf.dll. The TF_Notify function, also known as CtfImmNotify from
imm32.dll, uses a new convention for its third argument. These changes
are incompatible with current versions of ZoneAlarm Anti-Keylogger,
resulting in crashes in our main process.
This patch converts messages forwarded by ZoneAlarm Anti-Keylogger to
the new convention. If we detect the product and an incompatible version
of msctf.dll, then we hook TF_Notify and detect any message using the
old convention, and convert it to the new convention.
Differential Revision: https://phabricator.services.mozilla.com/D189518
Previously, we cached when a UIA client was blocked or when there were no UIA clients.
However, we did not cache the result when a UIA client was present but *not* blocked.
This isn't normally a problem because a11y is normally instantiated in this case, which means we won't try to do any client detection again this session.
However, if a11y is force disabled via the pref, we still do detection, but we don't instantiate.
This meant that a UIA client which hammered us with queries would keep triggering the detection code, since we weren't caching the result.
That resulted in severe performance degradation for impacted users.
To fix this, cache the UIA detection result even if we do allow a11y instantiation.
Differential Revision: https://phabricator.services.mozilla.com/D187869
The new detection code introduced in bug 1838123 doesn't work on Windows 10.
This patch:
1. Splits the Windows 11 code into its own function.
2. Refactors the system handle enumeration code into its own function which can be called with a lambda, since it is needed for both Windows 11 and Windows 10.
3. Adds code to detect clients on Windows 10 based on the old detection code before bug 1838123, with some noteworthy changes:
- Hooking the UIA window message doesn't work; our hook runs too late. It also doesn't work well for blocking; some clients will very likely poke us more than the maximum attempts in the old code (5 times).
- Instead, we run this code as part of LazyInstantiator::ShouldInstantiate, just as we do for all other client detection.
- This means we use the same UIA detection caching strategy; i.e. reset on foreground changes.
- It also means we reuse the same instantiator setting and block listing code in LazyInstantiator.
Differential Revision: https://phabricator.services.mozilla.com/D185627
The new detection code introduced in bug 1838123 doesn't work on Windows 10.
This patch:
1. Splits the Windows 11 code into its own function.
2. Refactors the system handle enumeration code into its own function which can be called with a lambda, since it is needed for both Windows 11 and Windows 10.
3. Adds code to detect clients on Windows 10 based on the old detection code before bug 1838123, with some noteworthy changes:
- Hooking the UIA window message doesn't work; our hook runs too late. It also doesn't work well for blocking; some clients will very likely poke us more than the maximum attempts in the old code (5 times).
- Instead, we run this code as part of LazyInstantiator::ShouldInstantiate, just as we do for all other client detection.
- This means we use the same UIA detection caching strategy; i.e. reset on foreground changes.
- It also means we reuse the same instantiator setting and block listing code in LazyInstantiator.
Differential Revision: https://phabricator.services.mozilla.com/D185627
Eventually, the bulk of this functionality should be moved to TextLeafRange.
In the meantime, let's get rid of the platform specific ugliness here.
Differential Revision: https://phabricator.services.mozilla.com/D185263
Eventually, the bulk of this functionality should be moved to TextLeafRange.
In the meantime, let's get rid of the platform specific ugliness here.
Differential Revision: https://phabricator.services.mozilla.com/D185263
get_selections is largely based on the old IAccessible2_3::get_selectionRanges method.
However, this makes use of HyperTextAccessibleBase::CroppedSelectionRanges, which didn't exist before.
It has also been updated to return IAccessibleText pointers as required by the new interface.
setSelections is entirely new, but relies on existing mechanisms to convert offsets and to add and remove selections.
Differential Revision: https://phabricator.services.mozilla.com/D185135
IAccessibleTextSelectionContainer::setSelections passes us IAccessibleText COM pointers to identify the target Accessibles.
We need to safely get a Gecko Accessible from such a COM pointer.
The client could hand us anything, so it's not safe to just static_cast without being certain that it's one of our Accessibles.
Instead, we use an internal IID to validate that it's an MsaaAccessible and return the correct pointer, after which we can easily get the Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D185134
get_selections is largely based on the old IAccessible2_3::get_selectionRanges method.
However, this makes use of HyperTextAccessibleBase::CroppedSelectionRanges, which didn't exist before.
It has also been updated to return IAccessibleText pointers as required by the new interface.
setSelections is entirely new, but relies on existing mechanisms to convert offsets and to add and remove selections.
Differential Revision: https://phabricator.services.mozilla.com/D185135
IAccessibleTextSelectionContainer::setSelections passes us IAccessibleText COM pointers to identify the target Accessibles.
We need to safely get a Gecko Accessible from such a COM pointer.
The client could hand us anything, so it's not safe to just static_cast without being certain that it's one of our Accessibles.
Instead, we use an internal IID to validate that it's an MsaaAccessible and return the correct pointer, after which we can easily get the Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D185134
The methods have already been updated to used unified cross-platform methods.
All that was preventing these from working was the IsLocal restriction in QueryInterface.
Differential Revision: https://phabricator.services.mozilla.com/D185253
This is now just an alias for HyperTextAccessible on all platforms.
This was done with the following bash script:
```
cd accessible
find -name HyperTextAccessibleWrap.h -delete
sed -i 's/#include "HyperTextAccessibleWrap.h"/#include "HyperTextAccessible.h"/;/"HyperTextAccessibleWrap.h",/d;s/HyperTextAccessibleWrap/HyperTextAccessible/g' `git grep -l HyperTextAccessibleWrap`
```
Differential Revision: https://phabricator.services.mozilla.com/D184796
This was done with the following Python script:
```
import re
cacheConsts = open("accessible/base/CacheConstants.h", "rt").read()
aliases = {
alias: atom
for atom, alias in
re.findall(
r'static constexpr nsStaticAtom\*\s+(.*?)\s+=\s+(nsGkAtoms::.*?);',
cacheConsts
)
}
RE_ATOM = re.compile(r'(fields->SetAttribute|(?:mCachedFields|aFields)->(?:GetAttribute|GetAttributeRefPtr|GetMutableAttribute|HasAttribute|Remove|SetAttribute)(?:<.+>)?)(\(\s*)(nsGkAtoms::[a-zA-Z_]+)')
def repl(m):
# Group 3 is the atom.
alias = aliases.get(m.group(3))
if not alias:
# No alias for this atom. Return input unaltered.
return m.group(0)
alias = "CacheKey::" + alias
# Groups 1 and 2 should be returned unaltered. Group 3 (the atom) is replaced
# with the alias.
return m.group(1) + m.group(2) + alias
for fn in (
# Found with: git grep -l 'ields->'
"accessible/base/CachedTableAccessible.cpp",
"accessible/base/nsAccessibilityService.cpp",
"accessible/base/TextLeafRange.cpp",
"accessible/generic/LocalAccessible.cpp",
"accessible/ipc/DocAccessibleParent.cpp",
"accessible/ipc/RemoteAccessible.cpp",
"accessible/ipc/RemoteAccessible.h",
"accessible/windows/sdn/sdnAccessible.cpp",
):
input = open(fn, "rt").read()
output = RE_ATOM.sub(repl, input)
open(fn, "wt").write(output)
```
Differential Revision: https://phabricator.services.mozilla.com/D184791
Role.h will soon be generated, but it is generated within the obj dir, so local includes won't work.
Our C++ style guide says we should prefer exported includes wherever possible anyway.
This was done with this shell command inside the accessible/ directory:
```
sed -i 's,#include "Role.h",#include "mozilla/a11y/Role.h",' `git grep -l '#include "Role.h"'`
```
Differential Revision: https://phabricator.services.mozilla.com/D183940
Mac and Android still override HandleAccEvent for platform specific behaviour other than firing the event.
The Android behaviour can be unified properly in future work.
ATK is the platform layer with the most churn because there were inconsistencies in the way local and remote events were handled.
I'm reasonably sure these were unintentional inconsistencies, so I've done my best to unify them.
Differential Revision: https://phabricator.services.mozilla.com/D183704
This takes an Accessible and a rect and calls the local or remote versions appropriately.
This avoids the duplication of conditional behaviour in PlatformFocusEvent and PlatformCaretMoveEvent.
Differential Revision: https://phabricator.services.mozilla.com/D183702
This was done with the following command in the accessible/ directory:
```
sed -i 's/\bProxy\(.*\)Event\b/Platform\1Event/' `git grep -l 'Proxy.*Event'`
```
Differential Revision: https://phabricator.services.mozilla.com/D183700
This is a hack that was implemented a long time ago before IAccessible2.
However, it violates the MSAA API, breaks Microsoft's Inspect tool and violates the Core/HTML AAM specs.
In terms of backwards compatibility, anyone who wants to really access web content will be using IAccessible2 anyway.
Also, Chromium has never implemented this hack.
The mappings were largely taken from the Core and HTML AAM specs.
Where those specs didn't specify an MSAA role, ROLE_SYSTEM_GROUPING has been used, which is the closest we can get to a generic mapping and is also used by Chromium for these cases.
Differential Revision: https://phabricator.services.mozilla.com/D183828
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
The window message we previously hooked no longer gets sent and the associated shared memory no longer seems to be created either.
Also, we don't seem to be notified about the load of UIAutomationCore.dll until after it has already instantiated a11y, which is obviously too late for us to hook anything.
Instead, we block UIA instantiation via LazyInstantiator, just as we do for MSAA/IA2:
1. Refactor CompatibilityUIA so that rather than being called by a hook, it simply allows the caller to query the process ids of any UIA clients.
2. CompatibilityUIA now searches handles in our process for named pipes created by UIA for communication with the remote process and then uses GetNamedPipeServerProcessId to get the process id on the other end of each pipe.
3. Refactor LazyInstantiator so that it first tries to get the MSAA/IA2 client process id, then calls CompatibilityUIA to get any UIA client process ids.
4. LazyInstantiator now handles setting the instantiator and blocking of clients for UIA as well as MSAA/IA2 using the same code.
5. Because UIA client detection can be expensive if clients repeatedly query us, cache the result. Reset that cache only when one of our windows comes to the foreground.
Differential Revision: https://phabricator.services.mozilla.com/D181958
The code previously called DefWindowProc to get a system generated client IAccessible. However, DefWindowProc doesn't do this and I'm fairly sure it never has.
Even if we use CreateStdAccessibleObject instead:
1. We crash in LazyInstantiator's destructor because we try to call into mWeakMsaaRoot, which doesn't exist in this case.
2. We crash when some clients call us because AddRef and Release assume that we've transplanted our ref count into mRealRootUnk, but we don't do that in the case of a fake root.
3. We don't (and can't) aggregate the fake root COM object, so QueryInterface would be asymmetric. This may well cause obscure crashes/leaks.
We could fix all of these issues, but since this has clearly never been used or relied upon, we should just remove it.
We already have stub implementations for key methods and the others will just fail as they always have.
There should be no visible change with this patch.
Differential Revision: https://phabricator.services.mozilla.com/D182864
If a11y is instantiated, we always want to return the real root.
Furthermore, we clear the instantiator prop anyway when we instantiate a11y.
Therefore, calling GetProp is wasteful if a11y is instantiated.
Instead, we now only call GetProp if a11y isn't instantiated yet.
Differential Revision: https://phabricator.services.mozilla.com/D182863
We use AccessibleObjectFromWindow to get a system generated IAccessible for the window.
While this works well enough, it first sends WM_GETOBJECT to our window, goes through our window proc, etc., which is pointless since it will return nothing.
We should just call CreateStdAccessibleObject directly instead, which is what the existing code ends up doing indirectly.
Differential Revision: https://phabricator.services.mozilla.com/D182862
On Windows, focus and caret move events include the caret rectangle.
This isn't used on other platforms.
To simplify the cross-platform interface (including Platform.h), remove the ifdefs from there.
However, we use ifdefs to avoid calculating the rectangle on non-Windows platforms, instead just sending an empty rectangle.
Differential Revision: https://phabricator.services.mozilla.com/D182138
