Я заметил в Process Monitor, что доступ к Mozilla Firefox через интерфейс IAccessible (MSAA) вызывает доступ к файлу Adobe Reader с именем «Accessibility.api».Когда я получаю доступ к Mozilla Firefox с помощью Microsoft Inspect.exe (с помощью MSAA), я не получаю доступ к этим файлам.
Это код (C ++), который вызывает около 28 обращений к файлу Accessibility.api.:
CComPtr<IAccessible> mainElement;
::AccessibleObjectFromWindow(mainWindowHandle, static_cast<DWORD>(OBJID_CLIENT), IID_IAccessible, reinterpret_cast<void**>(&mainElement));
Каждый вызов ::AccessibleChildren или IEnumVariant::Next также вызывает около 28 обращений на дочерний элемент.
Как можно предотвратить доступ к этим файлам, как это делает Inspect.exe?
Обновление 2018-11-30
Я получаю те же результаты с Chrome.
Adobe Reader не установлен как плагин в этих браузерах.
Я попытался переименовать файл Accessible.api (находится в C: \ Program Files (x86) \ Adobe \ Acrobat ReaderDC \ Reader \ plug_ins \ Accessibility.api), чтобы отключить его, но после этого я больше не могу получить доступ к элементам браузера.Получающиеся дочерние элементы отличаются.Inspect.exe (с использованием MSAA) или Ranorex Spy (без расширения браузера) не имеют этих проблем.Я также проверил результаты с помощью AccProbe , и этот инструмент генерирует те же результаты, что и я.
Обновление 2018-12-03
Похоже, что это влияет только на 32-битовые приложения.Inspect.exe и Ranorex Spy являются 64-разрядными приложениями.Мое приложение, а также AccProbe (установленный JRE является 32-разрядным) являются 32-разрядными.Поскольку Adobe Reader является 32-разрядным, я предполагаю, что это влияет только на 32-разрядные приложения.Я также мог воспроизвести это поведение с помощью 32-разрядной версии Ranorex Spy.
Теперь я знаю, что поведение не вызвано неправильной реализацией.Но вопрос, почему так много обращений к этому файлу Adobe Reader Accessibility.api сделано, все еще остается открытым ...