IAccessible (MSAA): Accessing Firefox/Chrome causing Adobe Accessibility.api calls
I noticed with Process Monitor that accessing Mozilla Firefox over the IAccessible (MSAA) Interface causes file accesses to an Adobe Reader file called "Accessibility.api". When I access Mozilla Firefox with Microsoft's Inspect.exe (using MSAA) I don't get these file accesses.
This is the code (C++) that causes about 28 accesses to the "Accessibility.api" file accesses:
CComPtr<IAccessible> mainElement;
::AccessibleObjectFromWindow(mainWindowHandle, static_cast<DWORD>(OBJID_CLIENT), IID_IAccessible, reinterpret_cast<void**>(&mainElement));
Every ::AccessibleChildren or IEnumVariant::Next call also causes about 28 accesses per child element.
How can I prevent these file accesses like Inspect.exe is doing?
Update 2018-11-30
I get the same results with Chrome.
Adobe Reader is not installed as plug-in on these Browsers.
I tried to rename the Accessible.api file (located in C:Program Files (x86)AdobeAcrobat Reader DCReaderplug_insAccessibility.api) to disable it but after that I can't access the browser elements any more. The resulting child-elements differ. Inspect.exe (using MSAA) or Ranorex Spy (without browser extension) don't have these problems. I checked the results also with AccProbe and this tool generates the same results like me.
Update 2018-12-03
It looks like that this affects only 32-bit applications. Inspect.exe and Ranorex Spy are 64-bit applications. My application and also AccProbe (installed JRE is 32-bit) are 32-bit. Because Adobe Reader is 32-bit I assume that's why only 32-bit applications are affected. I could also reproduce this behaviour with a 32-bit version of Ranorex Spy.
Now I know that the behaviour is not caused by a wrong implementation. But the question why so many accesses to this Adobe Reader Accessibility.api file are done is still open...
c++
google-chrome firefox adobe-reader iaccessible asked Nov 27 '18 at 9:09
GR84GR84
393
add a comment |
I noticed with Process Monitor that accessing Mozilla Firefox over the IAccessible (MSAA) Interface causes file accesses to an Adobe Reader file called "Accessibility.api". When I access Mozilla Firefox with Microsoft's Inspect.exe (using MSAA) I don't get these file accesses.
This is the code (C++) that causes about 28 accesses to the "Accessibility.api" file accesses:
CComPtr<IAccessible> mainElement;
::AccessibleObjectFromWindow(mainWindowHandle, static_cast<DWORD>(OBJID_CLIENT), IID_IAccessible, reinterpret_cast<void**>(&mainElement));
Every ::AccessibleChildren or IEnumVariant::Next call also causes about 28 accesses per child element.
How can I prevent these file accesses like Inspect.exe is doing?
Update 2018-11-30
I get the same results with Chrome.
Adobe Reader is not installed as plug-in on these Browsers.
I tried to rename the Accessible.api file (located in C:Program Files (x86)AdobeAcrobat Reader DCReaderplug_insAccessibility.api) to disable it but after that I can't access the browser elements any more. The resulting child-elements differ. Inspect.exe (using MSAA) or Ranorex Spy (without browser extension) don't have these problems. I checked the results also with AccProbe and this tool generates the same results like me.
Update 2018-12-03
It looks like that this affects only 32-bit applications. Inspect.exe and Ranorex Spy are 64-bit applications. My application and also AccProbe (installed JRE is 32-bit) are 32-bit. Because Adobe Reader is 32-bit I assume that's why only 32-bit applications are affected. I could also reproduce this behaviour with a 32-bit version of Ranorex Spy.
Now I know that the behaviour is not caused by a wrong implementation. But the question why so many accesses to this Adobe Reader Accessibility.api file are done is still open...
c++
google-chrome firefox adobe-reader iaccessible asked Nov 27 '18 at 9:09
GR84GR84
393
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54
add a comment |
I noticed with Process Monitor that accessing Mozilla Firefox over the IAccessible (MSAA) Interface causes file accesses to an Adobe Reader file called "Accessibility.api". When I access Mozilla Firefox with Microsoft's Inspect.exe (using MSAA) I don't get these file accesses.
This is the code (C++) that causes about 28 accesses to the "Accessibility.api" file accesses:
CComPtr<IAccessible> mainElement;
::AccessibleObjectFromWindow(mainWindowHandle, static_cast<DWORD>(OBJID_CLIENT), IID_IAccessible, reinterpret_cast<void**>(&mainElement));
Every ::AccessibleChildren or IEnumVariant::Next call also causes about 28 accesses per child element.
How can I prevent these file accesses like Inspect.exe is doing?
Update 2018-11-30
I get the same results with Chrome.
Adobe Reader is not installed as plug-in on these Browsers.
I tried to rename the Accessible.api file (located in C:Program Files (x86)AdobeAcrobat Reader DCReaderplug_insAccessibility.api) to disable it but after that I can't access the browser elements any more. The resulting child-elements differ. Inspect.exe (using MSAA) or Ranorex Spy (without browser extension) don't have these problems. I checked the results also with AccProbe and this tool generates the same results like me.
Update 2018-12-03
It looks like that this affects only 32-bit applications. Inspect.exe and Ranorex Spy are 64-bit applications. My application and also AccProbe (installed JRE is 32-bit) are 32-bit. Because Adobe Reader is 32-bit I assume that's why only 32-bit applications are affected. I could also reproduce this behaviour with a 32-bit version of Ranorex Spy.
Now I know that the behaviour is not caused by a wrong implementation. But the question why so many accesses to this Adobe Reader Accessibility.api file are done is still open...
c++
google-chrome firefox adobe-reader iaccessible asked Nov 27 '18 at 9:09
GR84GR84
393
I noticed with Process Monitor that accessing Mozilla Firefox over the IAccessible (MSAA) Interface causes file accesses to an Adobe Reader file called "Accessibility.api". When I access Mozilla Firefox with Microsoft's Inspect.exe (using MSAA) I don't get these file accesses.
This is the code (C++) that causes about 28 accesses to the "Accessibility.api" file accesses:
CComPtr<IAccessible> mainElement;
::AccessibleObjectFromWindow(mainWindowHandle, static_cast<DWORD>(OBJID_CLIENT), IID_IAccessible, reinterpret_cast<void**>(&mainElement));
Every ::AccessibleChildren or IEnumVariant::Next call also causes about 28 accesses per child element.
How can I prevent these file accesses like Inspect.exe is doing?
Update 2018-11-30
I get the same results with Chrome.
Adobe Reader is not installed as plug-in on these Browsers.
I tried to rename the Accessible.api file (located in C:Program Files (x86)AdobeAcrobat Reader DCReaderplug_insAccessibility.api) to disable it but after that I can't access the browser elements any more. The resulting child-elements differ. Inspect.exe (using MSAA) or Ranorex Spy (without browser extension) don't have these problems. I checked the results also with AccProbe and this tool generates the same results like me.
Update 2018-12-03
It looks like that this affects only 32-bit applications. Inspect.exe and Ranorex Spy are 64-bit applications. My application and also AccProbe (installed JRE is 32-bit) are 32-bit. Because Adobe Reader is 32-bit I assume that's why only 32-bit applications are affected. I could also reproduce this behaviour with a 32-bit version of Ranorex Spy.
Now I know that the behaviour is not caused by a wrong implementation. But the question why so many accesses to this Adobe Reader Accessibility.api file are done is still open...
c++
google-chrome firefox adobe-reader iaccessible c++
google-chrome firefox adobe-reader iaccessible asked Nov 27 '18 at 9:09
GR84GR84
393
asked Nov 27 '18 at 9:09
GR84GR84
393
edited Dec 4 '18 at 14:12
GR84
asked Nov 27 '18 at 9:09
GR84GR84
393
asked Nov 27 '18 at 9:09
GR84GR84
393
asked Nov 27 '18 at 9:09
GR84GR84
393
393
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54
add a comment |
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53496110%2fiaccessible-msaa-accessing-firefox-chrome-causing-adobe-accessibility-api-cal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53496110%2fiaccessible-msaa-accessing-firefox-chrome-causing-adobe-accessibility-api-cal%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
IAccessible is very, very old. So is not unlikely to hit providers that are ancient, like Adobe Reader. Today's better mouse trap is IUIAutomation, start reading here.
– Hans Passant
Nov 30 '18 at 10:41
Hello Hans, thank you for your comment. IAccessible may be old, but it's still supported. I tried UIAutomation but for me it was very unstable to use.
– GR84
Nov 30 '18 at 11:38
It is not very unstable in Inspect.exe. Do ask the real question to get the help you need.
– Hans Passant
Nov 30 '18 at 11:41
Sorry, but for me UIAutomation is not an option. IAccessible could be old, but it's also working well in Inspect.exe
– GR84
Nov 30 '18 at 11:54