1549202 - Expanded select elements fail to report being descended of document

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect, P3)

Description

[Joanmarie Diggs]

Attachment: test case: select.html

Steps to reproduce:

1. Launch Firefox with attached test case.
2. Launch attached accessible-event listener.
3. Press Tab until the select element gains focus.
4. Press Space to expand the combo box.

Expanded results: The accessible ancestry of the combo box would be the same for step 3 and step 4.

Actual results: The accessible ancestry of the combo box is different. Sample output:

Ancestors of focused [combo box | ]:
[document web | ]
[internal frame | ]
[scroll pane | ]
[panel | ]
[frame | Firefox Nightly]
[application | Firefox]
[desktop frame | main]

Ancestors of expanded [combo box | ]:
[frame | Firefox Nightly]
[application | Firefox]
[desktop frame | main]

Impact: Orca has a ton of logic which relies upon being able to distinguish widgets which are inside a document from those which are not. As far as the user is concerned, the combo box in step 3 is the same as the combo box in step 4 and should be treated as such.

Comment 1

[Joanmarie Diggs]

Attachment: accessible-event listener: expanded.py

Comment 2

[James Teh [:Jamie]]

This is due to e10s (multi-process). The select dropdown is rendered in the parent process, not the content process. As far as Gecko a11y is concerned, they are indeed entirely separate elements. The challenge is figuring out how to link them together, especially because content and parent are effectively separate trees from the parent's perspective.

Note that NVDA had this same issue in bug 1422176, but NVDA implemented its own workaround. Unfortunately, because of the way content process a11y works, this is going to require a slightly different implementation for each platform.

Comment 3

[James Teh [:Jamie]]

Now that we have a unified Accessible hierarchy covering both local and remote, it should be possible to fake return the <select> element Accessible as the parent of the select dropdown. Doing this in the other direction will be uglier, but I don't think any client depends on that, so we should address that elsewhere if we need it.

Note that Windows won't be able to benefit from this until Cache the World is done. That doesn't prevent this from being worked on, though; it will still benefit other platforms and Windows will get the benefit once CTW is enabled.

The ugly bit here will be creating a LocalAccessible specific to the ContentSelectDropdown. I don't love the idea of matching on id, but I'm not sure what else we can match on. We'll need to restrict this to privileged root documents or similar to prevent spoofing.

Comment 4

[James Teh [:Jamie]]

This does impact NVDA in some cases, for both <select> and <input> with <datalist>. See the NVDA GitHub issues linked in "see also". The datalist case may need to be detected differently, as I think it might be a different piece of front-end code, but the solution should be the same.

This causes annoying verbosity for users when it occurs.

Comment 5

[Morgan Reschenberg [:morgan]]

Attachment: Bug 1549202: Ensure ContentSelectDropdown local accessibles return the focused <select> remote accessible as their parent r?Jamie

Comment 6

[Morgan Reschenberg [:morgan]]

Waiting til soft freeze ends to land this, here's a try in the meantime https://treeherder.mozilla.org/jobs?repo=try&revision=c213b7e273e902f0a9753f361e0c40d787131ba7

Comment 7

[Morgan Reschenberg [:morgan]]

https://treeherder.mozilla.org/jobs?repo=try&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunning%2Cpending%2Crunnable&revision=c6a040dd6221c309ae4f977ba4393656fb2bd5fa&selectedTaskRun=TFgr41BJRUyxoipvfQGSsg.0

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1fbca7956efd
Ensure ContentSelectDropdown local accessibles return the focused <select> remote accessible as their parent r=Jamie

Comment 9

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/1fbca7956efd