Firefox 56+ : IAccessible.accNavigate(NAVRELATION_EMBEDS) fails with 0x80004005 (E_FAIL)

[Sylvain]

Hi all,

This article (https://developer.mozilla.org/en-US/docs/Web/Accessibility/AT-APIs/Differences/MSAA) says:

"enum { NAVRELATION_EMBEDS = 0x1009 };
This relation is used on the root accessible object for a top level Mozilla window, corresponding to what's returned for OBJID_CLIENT for that window. It points to the accessible object corresponding to the root of content in that window. This relation is very useful for finding the content quickly, and will be the proper method for finding content in Firefox 3 and beyond."

Since Firefox 3, I was using this method and it was working fine with this source code:
hr=AccessibleObjectFromWindow(w,(DWORD)OBJID_CLIENT,IID_IAccessible,(void**)&pAccessible);
if (SUCCEEDED(hr))
{
hr=pAccessible->accNavigate(0x1009,vtMe,&vtResult); // NAVRELATION_EMBEDS = 0x1009
...
}

But with Firefox 56, 57 and 58, it returns E_FAIL :-(

How are we supposed to do now to find the content?

(I have developed alternative source code to parse all the objects, looking for a ROLE_SYSTEM_DOCUMENT that is STATE_SYSTEM_FOCUSED and not STATE_SYSTEM_INVISIBLE, but performance is poor and having focus on the Firefox window is prerequisite, and this is a problem for me)

Thanks!

Sylvain

[jt...@mozilla.com]

Hi Sylvain,

There were certainly bugs in Firefox 56 and 57 which would have caused this problem. However, these should be fixed in 58, with one caveat:

When accessibility is first enabled (by retrieving the client accessible for the Firefox window), accessibles for web documents may not immediately be available. (Because they're now in another process, they get created asynchronously.) Thus, once you retrieve the root accessible, you may need to delay slightly before trying to use NAVRELATION_EMBEDS (or retry the call a few times) in order to get a successful result.

Does doing this fix the problem?
Failing that, does focusing the Firefox window before doing this fix the problem?
Finally, what version of Windows are you testing this with?

Thanks!

Jamie

[syl...@swsso.fr]

Hi Jamie,

Thanks for your answer. Unfortunately, this does not fix the problem, including when focusing the Firefox window before calling accNavigate().

Here is my source code:
// w is the main Firefox window handle ("MozillaWindowClass")
hr=AccessibleObjectFromWindow(w,(DWORD)OBJID_CLIENT,IID_IAccessible,(void**)&pAccessible);
if (FAILED(hr)) { TRACE((TRACE_ERROR,_F_,"AccessibleObjectFromWindow(IID_IAccessible)=0x%08lx",hr)); goto end; }

for (int i=0;i<50;i++) // test every second

{
hr=pAccessible->accNavigate(0x1009,vtMe,&vtResult); // NAVRELATION_EMBEDS = 0x1009

TRACE((TRACE_DEBUG,_F_,"accNavigate(NAVRELATION_EMBEDS)=0x%08lx",hr));
if (hr==S_OK) break;
Sleep(1000);
}

And the result is:
28/11-16:36:55:949 accNavigate(NAVRELATION_EMBEDS)=0x80004005
28/11-16:36:56:955 accNavigate(NAVRELATION_EMBEDS)=0x80004005
28/11-16:36:57:959 accNavigate(NAVRELATION_EMBEDS)=0x80004005
28/11-16:36:58:965 accNavigate(NAVRELATION_EMBEDS)=0x80004005
28/11-16:36:59:969 accNavigate(NAVRELATION_EMBEDS)=0x80004005
...

My testing environment is Windows 10 (10.0.15063) and Firefox 58.0b6 (64 bits).

Thanks!

Sylvain

[James Teh]

Hi Sylvain,

I can't reproduce this in Windows 10 with Firefox 58b6 64 bit. I wrote my
own complete test case so we can test with exactly the same code. It'd be
great if you could compile the following C++ code. Then, start Firefox,
load example.com and run the test case. Here's the code:

---

// embeds.cpp: Test NAVRELATION_EMBEDS.
// Compile with:
// cl /EHsc embeds.cpp user32.lib oleacc.lib ole32.lib oleaut32.lib

#include <windows.h>
#include <oleacc.h>
#include <iostream>

using namespace std;

// Tweak as needed to find the Firefox window.
// This title works if using a Firefox release
// with example.com loaded in the active tab.
const char WINDOW_TITLE[] = "Example Domain - Mozilla Firefox";

const long NAVRELATION_EMBEDS = 0x1009;

int main()
{
CoInitialize(NULL);
HWND window = FindWindow("MozillaWindowClass", WINDOW_TITLE);
cout << "Window " << window << endl;
if (!window) {
cout << "Failed to get window" << endl;
return 1;
}
IAccessible* rootAcc;
HRESULT hr = AccessibleObjectFromWindow(window, OBJID_CLIENT,
IID_IAccessible, (void**)&rootAcc);
if (FAILED(hr)) {
cout << "AccessibleObjectFromWindow failed with " << hr << endl;
return 1;
}
VARIANT child;
child.vt = VT_I4;
child.lVal = CHILDID_SELF;
VARIANT target;
for (int i = 0; i < 5; ++i) {
hr = rootAcc->accNavigate(NAVRELATION_EMBEDS, child, &target);
cout << "accNavigate result " << hr << endl;
if (hr == S_OK) {
target.pdispVal->Release();
break;
}
Sleep(1000);
}
rootAcc->Release();
}

---

When I do this, I get the following:

Window 006F0AFE
accNavigate result -2147467259
accNavigate result 0

So, the first try fails, but the second succeeds.

Jamie

> _______________________________________________
> dev-accessibility mailing list
> dev-acce...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-accessibility
>

[James Teh]

Were you setting the pref to force enable remote accessibility or to disable it? Those prefs are no longer necessary. Multi-process accessibility is now enabled by default. It'd be good if you can re-run these tests with a clean profile and no prefs changed.


Sent from a mobile device

> On 29 Nov 2017, at 5:25 pm, Sylvain Werdefroy <syl...@swsso.fr> wrote:
>
> Hi Jamie,
>

> Thanks for the test case!
>
> First of all: as my Firefox 58 was freshly reinstalled on my computer, the browser.tabs.remote.force-enable was not configured, that's why the test I ran yesterday failed... sorry for that.
>
> Now here are the results:
>
> Open Firefox and load example.com in the 1st tab:
> Window 0003086A

> accNavigate result -2147467259
> accNavigate result 0
>

> Test passed!
>
> But now try to open a 2nd tab, load example.com in this tab, close the 1st one, run the test case:
> Window 0003086A
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
>
> It seems to be a problem with multiple tabs... for example this test case always fails:
>
> Open Firefox, open a 2nd tab, example.com in this tab, close the 1st one, run the test case:
> Window 000E08BE
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
>
> And this one fails randomly:
>
> Open Firefox, open a 2nd tab, example.com in this tab, run the test case:
>
> Sometimes it fails:
> Window 00120890
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
> accNavigate result -2147467259
>
> Somtimes it succeeds:
> Window 00110338

> accNavigate result -2147467259
> accNavigate result 0
>

> Please note my Firefox version has been upgraded, I now run a 58.0b7.
>
> Sylvain

[James Teh]

Deleting the pref should be fine if that's the only thing you did. That does lead me to wonder why your results were different yesterday, though. Perhaps there was some confusion regarding the difference with multiple tabs?

I'll investigate multiple tabs some time soon. I thought I'd already investigated this and wasn't able to reproduce, but I'll do some more isolated testing.

Sent from a mobile device

> On 29 Nov 2017, at 5:41 pm, Sylvain Werdefroy <syl...@swsso.fr> wrote:
>
> Tests above where run with:
> browser.tabs.remote.force-enable=true
>
> After deleting this pref, result is the same.
>
> How to be sure I'm using a clean profile? (I'll try later today after uninstalling Firefox & Firefox Developer Edition and reinstall only the last one)

[syl...@swsso.fr]

Yes, I guess there was confusion regarding multiple tabs (or the new test case below) with my tests yesterday.

Here is a new test case that fails:

First replace FindWindow("MozillaWindowClass", WINDOW_TITLE) by FindWindow("MozillaWindowClass", NULL) in the source code, so you can test with some url changes without compiling each time.

Open Firefox, open example.com, run test case:
C:\swSSO\Firefox58\Debug>Firefox58.exe
Window 002412A0

accNavigate result -2147467259
accNavigate result 0

--> OK!

Run test case another time
C:\swSSO\Firefox58\Debug>Firefox58.exe
Window 002412A0
accNavigate result 0
--> Still OK!

Open mozilla.org in the same tab (no multi tab), run test case:
C:\swSSO\Firefox58\Debug>Firefox58.exe
Window 002412A0

accNavigate result -2147467259
accNavigate result -2147467259
accNavigate result -2147467259
accNavigate result -2147467259
accNavigate result -2147467259

--> Not OK... (and as you can see the window handle is unchanged, so this is not a FindWindow issue)

Thanks!

Sylvain

[James Teh]

Hi Sylvain,

Sorry for the delay in responding to this.

I was still unable to reproduce this myself. However, I've since had
confirmation from several parties previously experiencing this that this is
all working as expected in Firefox 59 beta. It'd be great if you could give
that a try and let me know if it fixes the problem for you.

Note that FindWindow("MozillaWindowClass", NULL) might find the wrong
window in some cases, as there can be top level windows for tool tips, etc.
Based on the output from the test case, I don't think this was the case for
you - it did succeed some of the time - but I thought it worth noting for
future tests.

Jamie

[syl...@swsso.fr]

Hi Jamie,

You're right, it's working as expected with Firefox 59 (tested with 59.0b7) :-)

First call still fails, but retry is OK :

C:\swSSO\Firefox58\Debug>Firefox58.exe

Window 00040872

accNavigate result -2147467259
accNavigate result 0

Sylvain