1804906 - Some IAccessible instances return "object not connected to server"

Status: RESOLVED WORKSFORME

(Core :: Disability Access APIs, defect)

Description

[dh.member]

Attachment: inspect-shows-error.png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36 OPR/93.0.0.0

Steps to reproduce:

While using the C++ MSAA COM API to navigate (i.e., IAccessible::get_accParent/get_accChild) through elements in a Firefox window in my C++ application, I find that some items in that hierarchy return errors. It would seem that whether I change the display scaling (PPI/DPI) seems to affect the success/failure of these calls. I am testing with this page open in Firefox: https://www.mozilla.org/en-US/privacy/firefox/

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0
I am using Windows 11 21H2.

Actual results:

Specifically, calls to IAccessible::accNavigate or IAccessible::accLocation return an error similar to: "object not connected to server" (HRESULT=0x800401FD).

Proof of this can be seen by using the Microsoft Accessibility Tool inspect.exe (https://learn.microsoft.com/en-us/windows/win32/winauto/inspect-objects), it will report "error getting role" or "error getting state" in the tree view on some of the IAccessible items. (See attached PNG.)

Expected results:

This normally returns properties/data about all items.
It seems as though the screen resolution/scaling of my monitor may affect whether this succeeds or not (speculation).
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0

Comment 1

[James Teh [:Jamie]]

Is there some way to manually refresh Inspect's tree? Does that "fix" this?

My guess is that there is some change in the UI which causes part of the a11y tree to be re-built. That should happen rarely, but it seems plausible if you are switching between windows, if a window's size changes, etc. If Inspect happened to query the tree as that was happening, it might retrieve an Accessible which dies before it can query all the relevant info.

Manually refreshing the tree (if possible) should allow Inspect to fetch the updated tree.

Comment 2

[dh.member]

Refreshing the tree is possible but does not resolve the error being shown. However, the C++ code we use to access the IAccessible instances is not showing that error any longer. Something was causing that for a while when it hadn't before, and has not shown that error since. It is still showing when I use the Microsoft utility (inspect.exe), but I'm not concerned about that at this time. It may be that there are circumstances in which Firefox returns these unwanted errors. It would be good to have that addressed, but in the context of this bug report for my particular case, I'm not going to worry about it for now.

Comment 3

[James Teh [:Jamie]]

I looked into this a bit with Inspect. I think the "error getting role" issue is caused by the fact that Firefox returns strings for IAccessible::get_accRole for certain elements which don't map well to an MSAA role. For example, if you call accRole on the parent of a content document, you will get this:
"browser, http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
This is technically not supported by the MSAA spec, but it was done many years ago before we had more expressive accessibility APIs like IAccessible2 and UI Automation. However, Inspect doesn't like it. We have bug 798492 to remove this string role hack, which would make Inspect happier.

I'm not sure why this causes an error etrieving state, since the state method isn't doing anything that doesn't fit the spec. The state error always seems to accompany the role error, so I'm guessing Inspect just ties these together somehow.

So, I don't think the Inspect errors you're seeing now are necessarily related to the CO_E_OBJNOTCONNECTED error you were seeing before. As noted above, the CO_E_OBJNOTCONNECTED error was likely related to something which caused the accessibility tree to re-built between your calls. It's also possible we had a bug for a short while which broke something here, but if we did, I can't reproduce that now and that is only likely to have been in Firefox Nightly.

I'm going to close this for now, since it seems that the original issue you were experiencing is no longer reproducible. Please reopen if the problem reappears.