1555228 - Fission a11y: Fix IAccessible::accChild for OOP iframes when window emulation is enabled

Status: VERIFIED FIXED

(Core :: Disability Access APIs, enhancement, P2)

Description

[James Teh [:Jamie]]

When window emulation is enabled (for screen readers which rely on this such as JAWS), events are fired with the emulated HWND. WM_GETOBJECT for the emulated HWND returns the COM proxy for the top level document (e.g. tab document) in the content process. However, IAccessible::accChild on this object fails for ids in out-of-process iframes (because they're in a different content process). This means that AccessibleObjectFromEvent fails, since it uses WM_GETOBJECT and accChild.

JAWS keys its buffers on the HWND (I saw this myself and confirmed with VFO), so additional emulated HWNDs is not feasible.

We're going to need to return a special IAccessible from WM_GETOBJECT which can handle this.

A horrible hack would be to just return the root accessible. If it's only used for AccessibleObjectFromEvent, we only fire events with negative child ids and accChild will do the right thing for those. However, AccessibleObjectFromWindow would certainly return the wrong thing. It might be enough for JAWS, but I'm not sure about ZoomText, SuperNova, etc.

Otherwise, we're going to need to find a way to return an IAccessible which forwards all of its calls to the remote document except for accChild. We could probably abuse the handler for this somehow. I'm a little uncomfortable with abusing the handler, since that means OOP iframes will fail altogether if the handler isn't registered (instead of the user just experiencing performance problems). That said, the perf problems without the handler are severe enough that users can't reasonably run without it, so maybe this doesn't matter.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug is a enhancement, but please change it back in case of error.

Comment 2

[James Teh [:Jamie]]

STR (with JAWS and Fission enabled):

1. Open this URL:
   data:text/html,<button>before</button><iframe src="https://google.com/notfound"></iframe><button>after</button>
2. Press tab.
   • Observe: JAWS says "before button"
3. Press tab.
   • Expected: JAWS says "Error 404..."
   • Actual: JAWS says "before button"
4. Press tab.
   • Expected: JAWS says "Google link"
   • Actual: JAWS says "before button"

Comment 3

[James Teh [:Jamie]]

Attachment: Bug 1555228: When window emulation is enabled, use the root accessible to answer IAccessible::accChild queries for ids in OOP iframes.

When window emulation is enabled, each tab document gets its own HWND.
OOP iframes get the same HWND as their tab document and fire events with that HWND.
However, the root accessible for the HWND (the tab document) can't return accessibles for OOP iframes.
Therefore, we must get the root accessible from the main HWND and call accChild on that instead.

We must do this in the parent process, but the tab document accessible is in the content process.
Although OOP a11y clients talk directly to the content process, the clients that need window emulation are in-process.
All in-process client calls get intercepted by AccessibleHandler, so we can deal with this forwarding in AccessibleHandler.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0b01f82078b7
When window emulation is enabled, use the root accessible to answer IAccessible::accChild queries for ids in OOP iframes. r=yzen

Comment 5

[Andreea Pavel [:apavel]]

https://hg.mozilla.org/mozilla-central/rev/0b01f82078b7

Comment 6

[Bogdan Maris, Desktop QA]

Reproduced the initial issue described in comment 2 using an old nightly 2020-02-03 before the fix. Verified that using latest Nightly 76.0a1 on Windows 10 64bit the expected behavior is the one received.