1422176 - NVDA doesn't switch to browse mode with alt+upArrow in expanded select (AKA accParent incorrect on e10s select dropdowns)

Status: RESOLVED WORKSFORME

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

Description

[James Teh [:Jamie]]

STR:
1. Start NVDA and Firefox.
2. Open this URl: data:text/html,<select size="1"><option>a</option></select>
3. Press control+home to ensure you are at the top of the document and that the select gets focus. NVDA should remain in browse mode.
4. Press alt+downArrow to expand the select. NVDA should switch to focus mode.
5. Press alt+upArrow (or escape) to collapse the select.
Expected: The select should collapse and NVDA should switch to browse mode.
Actual: The select collapses, but NVDA remains in focus mode.

This works fine in single process mode, but breaks with e10s. From bug 1309271 comment 24:

> These select popups are generated by the chrome process in response to ipc messaging that scrapes and ships the option data over [1]. Once on the parent side, a xul popup gets created that takes focus away from content. 
> I highly doubt these two elements get associated properly in the a11y tree. ...
> [1] http://searchfox.org/mozilla-central/source/toolkit/modules/SelectContentHelper.jsm

There is indeed no association to the content document, so NVDA doesn't realise the alt+upArrow command should be associated with that document. For the same reason, you also can't force browse mode with NVDA+space while a select is expanded.

Fixing this is going to be nasty. Ideally, accParent on the XUL menupopup accessible should return the select accessible in content. There are two challenges:

1. How to get the content accessible for the select. We should be able to use COM to talk to the content document accessible directly and call IAccessible::accFocus. I confirmed that this does return the select.
2. How to special case accParent to handle this in a way which isn't too ugly. The problem is that this XUL menupopup accessible probably has no idea it has anything to do with content, and this is Windows specific. It seems we might already have a separate Windows AccessibleWrap class for these controls, so that's a good start.

Not high priority, since it's easy enough to work around and many users probably don't expand combo boxes, but still something we should deal with at some point.

Comment 1

[James Teh [:Jamie]]

Now that we're definitely not moving to select in content processes (bug 1421229 has been wontfixed), we're definitely going to need to deal with this at some point.

Comment 2

[James Teh [:Jamie]]

NVDA has worked around this now, so the STR above now work as expected. Our implementation is still technically incorrect. However, no one else on Windows cares at this point, so I'm closing this for now. Note that this is still a problem on Linux (see bug 1549202), but the fix for this is unfortunately going to be platform specific.