User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0

Steps to reproduce:

Using, for example, Accessibility Insights for Windows https://accessibilityinsights.io/docs/en/windows/overview/

Click on a site (I used http://example.com) in Firefox and observe the accessibility tree reported to the accessibility tool.

Actual results:

In Firefox 91, this is window\pane\document 'title'... where if you inspect the document element the ValuePattern.Value is the URL of the document. (see attached image Firefox 91.png). This is correct.

In Firefox 92 (Developer edition), this is window\pane and then nothing further. The document, and the document contents are missing.

Expected results:

Firefox 92 should behave in the same way as 91, and return the document and its contents to the requesting accessibility tool (along with the URL of that document)

The Bugbug bot thinks this bug should belong to the 'DevTools::Accessibility Tools' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

I'd be interested to know if you still see this if you, for example, start a screen reader (even Windows Narrator will do) and focus the document before trying to inspect it. I'm wondering whether the accessibility engine is still starting up when the inspector tries to access the document.

It looks like if I focus on a particular element in the document (using example.com, clicking on the "This domain is for use..." paragraph) the accessibility tree will be down populated to that element, including the document level. Windows narrator narrates that element. However, if I don't focus on an element and just click on the document background, the document is not populated in the accessibility tree.

Further testing indicates this may just be an artefact of Accessibility Insights UI. I think what is happening is that Firefox is correctly reporting the focused element when its clicked on, and from that navigating upwards through the parent chain gets you to the document and the Firefox window. Navigating downwards starting from the window to the document still doesn't work, though.

Further investigation reveals that calling AccessibleChildren on the propertyPage object that is the parent of the document object returns a count of 0, and a result of S_FALSE. The accCount of the object, though, is correctly 1, and calling accNavigate(NAVDIR_FIRSTCHILD, 0) on the property page object does return the document object.

So possibly just something broken on enumerating the document object as a child of the propertyPage object?

Note to QA: This is in an a11y Bugzilla component, so doesn't need the access keyword. The access keyword is only required on bugs outside of a11y components. Thanks.

Thanks for the investigation, Alex. That was super helpful. It seems IEnumVARIANT reports as available but is broken on remote OuterDocAccessibles.

Prior to this patch, we reported that we supported IEnumVARIANT, but it wouldn't return any children, causing the oleacc AccessibleChildren function to report no children to clients.
This is tricky to support due to the special COM proxy stuff we have to do for remote children without the cache.
There's no benefit to IEnumVARIANT with only one child anyway, so it's easiest to just say we don't support it.
The oleacc AccessibleChildren function will detect this and fall back to IAccessible::get_accChild instead.

https://hg.mozilla.org/mozilla-central/rev/becf8aa7735e

Please nominate this for Beta approval when you get a chance.

Alex, would you mind verifying that the issue is fixed for you in the latest Firefox Nightly? I just want to be extra sure before I request uplift to beta. Thanks.

Confirmed fixed in Nightly 93.0a1 2021-08-17, thank you!

Comment on attachment 9236368 [details]
Bug 1725449: Don't support IEnumVARIANT for local OuterDocAccessibles with remote children when the cache isn't enabled.

Beta/Release Uplift Approval Request

• User impact if declined: Windows accessibility inspection tools will be unable to inspect the accessibility tree in Firefox, which is problematic for web developers. This might also cause problems for some assistive technology tools, though there hasn't been any report of this so far.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): Simple, isolated patch which only impacts bulk retrieval of a11y children for web document containers.
• String changes made/needed:

Comment on attachment 9236368 [details]
Bug 1725449: Don't support IEnumVARIANT for local OuterDocAccessibles with remote children when the cache isn't enabled.

Approved for 92.0b6.

https://hg.mozilla.org/releases/mozilla-beta/rev/bff53c71141c

is there any chance that the fix of this bug that you made for v 93 will also be applied to v 92 or it will go into production with it ?

See comments 17 & 18. The fix will be in 92.0b6 shipping in a few hours.