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

VERIFIED FIXED in Firefox 57

Status

()

defect
VERIFIED FIXED
2 years ago
2 years ago

People

(Reporter: support, Assigned: Jamie)

Tracking

({regression})

56 Branch
mozilla58
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox-esr52 unaffected, firefox56 wontfix, firefox57 fixed, firefox58 fixed)

Details

Attachments

(1 attachment)

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.
IAccessible::accNavigate(NAVRELATION_EMBEDS) fails in the primary Firefox window. But succeeds in a secondary window.
IAccessible::accNavigate(NAVRELATION_EMBEDS) fails after upgrading to version 56.0. The last version where still worked was probably 55.
Component: Untriaged → Disability Access APIs
Product: Firefox → Core
Jamie, any ideas?
Flags: needinfo?(jteh)
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.
Flags: needinfo?(jteh)
My mistake. It returns E_NOTIMPL, not E_FAIL.

Multiprocess Windows 	0/1 (Disabled by accessibility tools)
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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.
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).
Happy for this to be assigned to me. I'm pretty sure this is a trivial fix and I'm testing a patch locally.
Just feel free to grab a bug whenever you work on it or think you have a fix. :)
Assignee: nobody → jteh
Status: NEW → ASSIGNED
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 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.
Attachment #8915466 - Flags: review+
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/00bed5482a23
Implement accNavigate in Windows a11y LazyInstantiator. r=MarcoZ
Attachment #8915466 - Flags: review?(aklotz)
we are also facing the same issue with Firefox 56.0 and 57.0b5, is that anyway we can get a quick fix?
Duplicate of this bug: 1406001
(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 ?
https://hg.mozilla.org/mozilla-central/rev/00bed5482a23
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla58
Seems like this is biting enough users in the wild to justify a Beta approval request. Please do so :-)
Blocks: 1323069
Flags: needinfo?(jteh)
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.
Flags: needinfo?(jteh)
Flags: needinfo?(support)
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.
Flags: needinfo?(support)
See this page: https://www.mozilla.org/en-US/firefox/channel/desktop/#nightly
Thanks.
Flags: needinfo?(support)
(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.
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.
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.
After disabling multi-process, everything works well.
Flags: needinfo?(support)
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?
Filed bug 1407475 to deal with the multi-process case.
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
Attachment #8915466 - Flags: approval-mozilla-beta?
Verified fixed for single process; see comment 26, comment 27.
Status: RESOLVED → VERIFIED
Comment on attachment 8915466 [details]
Bug 1405065: Implement accNavigate in Windows a11y LazyInstantiator.

Recent regression, beta57+
Attachment #8915466 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
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
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.
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.
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.
(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.
(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.
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 ?
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.
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/
(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?
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
(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.
(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
(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.
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.
You need to log in before you can comment on or make changes to this bug.