1405065 - Accessibility tools cannot find web content because IAccessible::accNavigate(NAVRELATION_EMBEDS) returns E_NOTIMPL

Status: VERIFIED FIXED

(Core :: Disability Access APIs, defect)

Description

[gindi]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:56.0) Gecko/20100101 Firefox/56.0
Build ID: 20170926190823

Steps to reproduce:

Get IAccessible object with AccessibleObjectFromWindow(OBJID_CLIENT);
Try to get web content's IAccessible object with IAccessible::accNavigate(NAVRELATION_EMBEDS).


Actual results:

IAccessible::accNavigate(NAVRELATION_EMBEDS) returns E_FAIL.


Expected results:

Should return 0 and retrieve the IAccessible object.

Comment 1

[gindi]

IAccessible::accNavigate(NAVRELATION_EMBEDS) fails in the primary Firefox window. But succeeds in a secondary window.

Comment 2

[gindi]

IAccessible::accNavigate(NAVRELATION_EMBEDS) fails after upgrading to version 56.0. The last version where still worked was probably 55.

Comment 3

[Marco Zehe (:MarcoZ)]

Jamie, any ideas?

Comment 4

[James Teh [:Jamie]]

is Firefox multi-process mode enabled? You can check this in about:support. Please look for "Multiprocess Windows" and provide the value it shows.

The summary says E_NOTIMPL, but your description notes E_FAIL. Can you please clarify?

Marco, does a11y work at all for e10s in Firefox 56?

Regardless, testing reveals that accNavigate with NAVRELATION_EMBEDS returns E_FAIL in Firefox nightly with e10s enabled. With e10s disabled (or a non-e10s window), it works as expected.

Simple testing instructions with the NVDA Python console:
1. Switch to the Firefox window you want to test.
2. Open the NVDA Python console by pressing NVDA+control+z.
3. Enter this command:
fg.IAccessibleObject.accNavigate(0x1009, 0)
If it succeeds, you should get a Dispatch object back; e.g. <comtypes.client.lazybind.Dispatch object at 0x05185A50>
If it fails, you'll get a traceback.

Comment 5

[gindi]

My mistake. It returns E_NOTIMPL, not E_FAIL.

Multiprocess Windows 	0/1 (Disabled by accessibility tools)

Comment 6

[James Teh [:Jamie]]

I can confirm this in Firefox 56, though it's rather obscure and there are a few different issues here which confuse things.

First, while NAVRELATION_EMBEDS does fail (E_FAIL) in e10s, that is not relevant here. I'll need to file a separate bug for that.

It seems accNavigate on the root accessible with any navDir returns E_NOTIMPL in Firefox 56 and later, but:
1. This is intermittent. It does occur the majority of runs, but not always. However, if it happens once in a run, it will keep occurring.
2. It only occurs when called on the IAccessible interface. If you QueryService to IAccessible2, it works just fine. That is *very* strange.
3. I'm pretty certain this is Gecko and not the oleacc proxy. I bypassed oleacc proxying by directly using WM_GETOBJECT and ObjectFromLresult instead of AccessibleObjectFromWindow.

To test accNavigate on the root IAccessible (not IAccessible2) with the NVDA Python console:
1. Focus the Firefox window you want to test.
2. Open the NVDA Python console with NVDA+control+z.
3. Enter this command:
import IAccessibleHandler as iah; a = oleacc.AccessibleObjectFromEvent(focus.windowHandle, -4, 0); a[0].accNavigate(7, 0)
Note that I use 7 here (NAVDIR_FIRSTCHILD) instead of NAVRELATION_EMBEDS to avoid the confusion with the aforementioned e10s bug.

Comment 7

[James Teh [:Jamie]]

18:04.06 INFO: Last good revision: 8f2434d1648b623c06326f582fd431cbe533c6a8
18:04.06 INFO: First bad revision: 7bdf1aa4e51482e51c0104845dc249cdc027a809
18:04.06 INFO: Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=8f2434d1648b623c06326f582fd431cbe533c6a8&tochange=7bdf1aa4e51482e51c0104845dc249cdc027a809

This suggests bug 1323069 is the cause of the regression.

Comment 8

[James Teh [:Jamie]]

The issue is that this accNavigate call is hitting the lazy instantiator used to only instantiate a11y when it's actually needed. The instantiator doesn't yet implement accNavigate, thus E_NOTIMPL (accessible/windows/msaa/LazyInstantiator.cpp line 815).

Comment 9

[James Teh [:Jamie]]

Happy for this to be assigned to me. I'm pretty sure this is a trivial fix and I'm testing a patch locally.

Comment 10

[Marco Zehe (:MarcoZ)]

Just feel free to grab a bug whenever you work on it or think you have a fix. :)

Comment 11

[David Bolter [:davidb] (NeedInfo me for attention)]

Setting status, assuming this affects 57 and 58. At this point we're very unlikely to take a patch in 57 unless we feel the bug is super serious, and the patch is low risk.

Comment 12

[James Teh [:Jamie]]

Attachment: Bug 1405065: Implement accNavigate in Windows a11y LazyInstantiator.

The first accessibility client to ask for the root accessible will get a surrogate LazyInstantiator object. That instantiates accessibility if appropriate and then passes calls through.
However, it previously didn't implement accNavigate, which broke things for clients that used this on the root.
In particular, this was bad for NAVRELATION_EMBEDS, which is used by some clients to retrieve the tab document.
This patch simply passes accNavigate through to the real accessible, just as is already done for other methods.

Review commit: https://reviewboard.mozilla.org/r/186668/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/186668/

Comment 13

[Marco Zehe (:MarcoZ)]

Comment on attachment 8915466 [details]
Bug 1405065: Implement accNavigate in Windows a11y LazyInstantiator.

https://reviewboard.mozilla.org/r/186668/#review191758

Stealing review from aklotz for this straight-forward patch.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/00bed5482a23
Implement accNavigate in Windows a11y LazyInstantiator. r=MarcoZ

Comment 15

[Rajesh VR]

we are also facing the same issue with Firefox 56.0 and 57.0b5, is that anyway we can get a quick fix?

Comment 17

[Robinson]

(In reply to David Bolter [:davidb] (NeedInfo me for attention) from comment #11)
> Setting status, assuming this affects 57 and 58. At this point we're very
> unlikely to take a patch in 57 unless we feel the bug is super serious, and
> the patch is low risk.

Hi David,

We have an application which uses IAccessible API interface. Hunderds of our customers are affected by this issue. Is it possible to get a quick fix ?

Comment 18

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/00bed5482a23

Comment 19

[Ryan VanderMeulen [:RyanVM]]

Seems like this is biting enough users in the wild to justify a Beta approval request. Please do so :-)

Comment 20

[James Teh [:Jamie]]

gindi (or anyone else experiencing this), could you please verify ASAP that it is fixed for you in the latest nightly? We need this in order to justify an uplift to Firefox beta. Thanks.

Comment 21

[gindi]

Sorry for ignorance, but I cannot find the latest nightly Firefox. The newest version I found is 57.0b6 (64-bit), build id 20171005195903, and accNavigate still fails.

Comment 22

[James Teh [:Jamie]]

See this page: https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly
Thanks.

Comment 23

[Rajesh VR]

(In reply to gindi from comment #21)
> Sorry for ignorance, but I cannot find the latest nightly Firefox. The
> newest version I found is 57.0b6 (64-bit), build id 20171005195903, and
> accNavigate still fails.

I have downloaded the Firefox Nightly 58 from -> https://www.mozilla.org/en-US/firefox/58.0a1/releasenotes/

And I have tried with this nightly version (58.0a1), result is: "accNavigate" failed with "E_FAIL" error code.

Comment 24

[gindi]

Sorry, at first I installed that version but somehow restarted to the older version. Now restarted to the nightly. Results:

IAccessible::accNavigate(NAVRELATION_EMBEDS) now always returns E_FAIL (previously was E_NOTIMPL).

And enabling MSAA accessibility now does not work well. For some tabs, AccessibleObjectFromPoint enables accessibility, for some not, for some it seems to enable after several attempts, or it enables only in one of inactive tabs and not in the active tab... Still need more testing to say exactly what happens.

Comment 25

[James Teh [:Jamie]]

I neglected to realise there is also a secondary bug here. Can you please open Firefox Options and disable multi-process, then restart and test again? That is more similar to the current state of things in Firefox 56. This does raise an interesting point, though: we really need to fix the multi-process issue here as well in order for this fix to be helpful if we decide to ship a11y multi-process with 57 final.

Comment 26

[gindi]

After disabling multi-process, everything works well.

Comment 27

[Rajesh VR]

After disabling multi-process with Firefox Nightly (58.0a1), everything works fine. So looking forward to the final fix with multi-process.
Is there anyway we can get the final fix in Firefox 57?

Comment 28

[James Teh [:Jamie]]

Filed bug 1407475 to deal with the multi-process case.

Comment 29

[James Teh [:Jamie]]

Comment on attachment 8915466 [details]
Bug 1405065: Implement accNavigate in Windows a11y LazyInstantiator.

Approval Request Comment
[Feature/Bug causing the regression]: Regression introduced by bug 1323069 (lazy instantiation of accessibility on Windows).
[User impact if declined]: Breaks accessibility clients that use NAVRELATION_EMBEDS to access the tab document. Note that this technique is prominently documented on MDN, so it's reasonable that a11y clients would use it. Several people report they are affected by this (comment 0, comment 15, comment 17).
[Is this code covered by automated tests?]: No; we don't have a mechanism for platform a11y testing.
[Has the fix been verified in Nightly?]: yes
[Needs manual test from QE? If yes, steps to reproduce]: no
[List of other uplifts needed for the feature/fix]: none
[Is the change risky?]: no
[Why is the change risky/not risky?]: Low risk. Trivial patch which only touches one a11y method and thus should at worst only affect that method. Code simply forwards to the existing implementation of this method which we've been using for years.
[String changes made/needed]: none

Comment 30

[James Teh [:Jamie]]

Verified fixed for single process; see comment 26, comment 27.

Comment 31

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8915466 [details]
Bug 1405065: Implement accNavigate in Windows a11y LazyInstantiator.

Recent regression, beta57+

Comment 32

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-beta/rev/614027e7d4e3

Comment 33

[Rajesh VR]

Tested Firefox 57.0b8 (64-bit) on Windows 8.1 Pro (64-bit) machine with Multi-process mode then "accNavigate" is returning "E_POINTER" and not able to find web page objects.

But when we disable Multi-process mode, then "accNavigate" works fine and the function call "hr = pServProv->QueryService(refguid, IID_ISimpleDOMNode,(void **)&pNode);" is failing with error: "The specified module could not be found".

Code snippet is given below:

IAccessible *pAccBrowser = NULL;
hr = AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&pAccBrowser);
hr = pAccBrowser->accNavigate(NAVRELATION_EMBEDS,vtStart,&vtResult); //SUCCESS
IDispatch *pDisp = vtResult.pdispVal;
IAccessible *pAccDoc = NULL; 
hr = pDisp->QueryInterface(IID_IAccessible,(void **)&pAccDoc); //SUCCESS
hr = pAccDoc->QueryInterface(IID_IServiceProvider, (void **)&pServProv); //SUCCESS
ISimpleDOMNode *pNode = NULL; 
hr = pServProv->QueryService(refguid, IID_ISimpleDOMNode,(void **)&pNode); //FAILS -> 0x8007007e The specified module could not be found

Comment 34

[Rajesh VR]

Sorry kindly see the change in first sentence (different error code):

Tested Firefox 57.0b8 (64-bit) on Windows 8.1 Pro (64-bit) machine with Multi-process mode then "accNavigate" is returning "E_FAIL" and not able to find web page objects.

Comment 35

[gindi]

I recently had the IID_ISimpleDOMNode problem and I think it is unrelated. It was because my client app is 32-bit, and Firefox now is 64-bit, even if it is in the 32-bit Program Files directory. The Firefox 32-bit proxy dll probably is still registered (in registry), but the dll file is missing. To solve it, I took an old 32-bit proxy dll and used it with my app. I didn't want to register it, therefore instead used another way - activation context + manifest.

Comment 36

[Rajesh VR]

Today we tested Firefox beta 57.0b9 (64-bit) on Windows 10 Pro (64 bit) with single-process mode (e10s disabled), then found that "accNavigate" is returning "E_NOTIMPL" and not able to find web page objects.

Comment 37

[James Teh [:Jamie]]

(In reply to Rajesh VR from comment #36)
> Today we tested Firefox beta 57.0b9 (64-bit) on Windows 10 Pro (64 bit) with
> single-process mode (e10s disabled), then found that "accNavigate" is
> returning "E_NOTIMPL" and not able to find web page objects.

I can't reproduce this in 57.0b9 with accnavigate(NAVRELATION_EMBEDS) on the root (OBJID_CLIENT) accessible for the HWND. I get an accessible every time. Can you please re-test (b10 is now out anyway)? Also, can you please describe your test procedure, including exactly what parameters you are using and how you retrieved the accessible? Thanks.

Comment 38

[Rajesh VR]

(In reply to James Teh [:Jamie] from comment #37)
> I can't reproduce this in 57.0b9 with accnavigate(NAVRELATION_EMBEDS) on the
> root (OBJID_CLIENT) accessible for the HWND. I get an accessible every time.
> Can you please re-test (b10 is now out anyway)? Also, can you please
> describe your test procedure, including exactly what parameters you are
> using and how you retrieved the accessible? Thanks.

Tested Firefox beta 57.0b10 with accnavigate(NAVRELATION_EMBEDS) on the root (OBJID_CLIENT) accessible for the HWND, it is working fine on Windows 10 both 32 bit and 64 bit machines. And it is failing for both Windows 7 and Windows 8.1 machines.
For code snippet, please see comment #33.

Comment 39

[Rajesh VR]

Jamie, we tested Firefox beta 57.0b11 and the result was same as comment #38. can you let us know when you are planning to provide the fix for Windows 7 and Windows 8 ?

Comment 40

[Brettucci]

This is my first time digging into Firefox bugs, so forgive me if I'm just not understanding the information here. It looks like this bug is already fixed in the version 58 nightly builds. I just installed version 58 and the problem is still reproducible for me.

Comment 41

[Brettucci]

I should have been more clear in my comment above. This is where I grabbed the build from...

https://www.mozilla.org/en-US/firefox/58.0a1/releasenotes/

Comment 42

[James Teh [:Jamie]]

(In reply to Brettucci from comment #40)
> This is my first time digging into Firefox bugs, so forgive me if I'm just
> not understanding the information here. It looks like this bug is already
> fixed in the version 58 nightly builds.

Your understanding is correct. :)

> I just installed version 58 and the
> problem is still reproducible for me.

Beyond what was provided in the initial description (comment 0), can you provide exact steps to reproduce; e.g. exact functions called?
What tool are you testing with?
Do you get E_NOTIMPL or E_FAIL?
Is Firefox in the foreground or in the background when you trigger the accNavigate call?

Comment 43

[Rajesh VR]

We tested Firefox beta 57.0b13 and shows "QueryService" API is failing with error code 127 on Windows 7 machines. Sample code is given below:

// header files
#include "ISimpleDOMNode.h"
#include "ISimpleDOMText.h"
#include "ISimpleDOMDocument.h"

// GUIDs
const GUID refguid = {0x0c539790, 0x12e4, 0x11cf, 0xb6, 0x61, 0x00, 0xaa, 0x00, 0x4c, 0xd6, 0xd8};
const IID IID_ISimpleDOMNode= {0x1814ceeb,0x49e2,0x407f,0xaf,0x99,0xfa,0x75,0x5a,0x7d,0x26,0x07};
const IID IID_ISimpleDOMText= {0x4e747be5,0x2052,0x4265,0x8a,0xf0,0x8e,0xca,0xd7,0xaa,0xd1,0xc0};
const IID IID_ISimpleDOMDocument= {0x0D68D6D0,0xD93D,0x4d08,0xA3,0x0D,0xF0,0x0D,0xD1,0xF4,0x5B,0x24};

 #ifndef NAVRELATION_EMBEDS
	#define NAVRELATION_EMBEDS 0x1009 
 #endif
/////////////////////////////////////

IAccessible *pAccBrowser = NULL;
hr = AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&pAccBrowser); //SUCCESS
hr = pAccBrowser->accNavigate(NAVRELATION_EMBEDS,vtStart,&vtResult); //SUCCESS
IDispatch *pDisp = vtResult.pdispVal;
IAccessible *pAccDoc = NULL; 
hr = pDisp->QueryInterface(IID_IAccessible,(void **)&pAccDoc); //SUCCESS
IServiceProvider *pServProv = NULL; 
hr = pAccDoc->QueryInterface(IID_IServiceProvider, (void **)&pServProv); //SUCCESS
ISimpleDOMNode *pNode = NULL; 
hr = pServProv->QueryService(refguid, IID_ISimpleDOMNode,(void **)&pNode); //FAILED with error code 127 on Windows 7 machines

Comment 44

[James Teh [:Jamie]]

(In reply to Rajesh VR from comment #43)
> We tested Firefox beta 57.0b13 and shows "QueryService" API is failing with
> error code 127 on Windows 7 machines.

This sounds like a different bug, since to get this far, NAVRELATION_EMBEDS must have succeeded. Please file a new bug. Also, please note in the bug summary that this is related to ISimpleDOM, since that is probably a very relevant factor. Thanks.

Comment 45

[Rajesh VR]

(In reply to James Teh [:Jamie] from comment #44)
 
> This sounds like a different bug, since to get this far, NAVRELATION_EMBEDS
> must have succeeded. Please file a new bug. Also, please note in the bug
> summary that this is related to ISimpleDOM, since that is probably a very
> relevant factor. Thanks.

Jamie, created a new ticket for this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1414790

Comment 46

[Brettucci]

(In reply to James Teh [:Jamie] from comment #42)
> (In reply to Brettucci from comment #40)
> > This is my first time digging into Firefox bugs, so forgive me if I'm just
> > not understanding the information here. It looks like this bug is already
> > fixed in the version 58 nightly builds.
> 
> Your understanding is correct. :)
> 
> > I just installed version 58 and the
> > problem is still reproducible for me.
> 
> Beyond what was provided in the initial description (comment 0), can you
> provide exact steps to reproduce; e.g. exact functions called?
> What tool are you testing with?
> Do you get E_NOTIMPL or E_FAIL?
> Is Firefox in the foreground or in the background when you trigger the
> accNavigate call?

I just tried the nightly build for 58 and I saw the same broken behavior. I then tried 59 and things seem to be working properly for me again.

To follow up on your question though...

There unfortunately isn't much other information. My reproduction steps are very similar to what is already above.

We get a window handle for FireFox's window. We make sure to walk up the tree of Windows to get FF's top level window. We call AccessibleObjectFromWindow() for that window and use that accessibility root object to call pIAccRoot->accNavigate( NAVRELATION_EMBEDS, ... ). The result we see from the call is E_NOTIMPL.

Comment 47

[James Teh [:Jamie]]

As well as comment 46, we've had additional confirmation from a vendor previously experiencing this issue that NAVRELATION_EMBEDS is working as expected in Firefox 59.