1722621 - Screen readers not reading Firefox autofill options

Status: RESOLVED FIXED

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

Description

[acawai]

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

Steps to reproduce:

Below steps with Firefox 91b7 and JAWS version 2021.2107.12

1. Open webpage with address form (for example https://www.freedomscientific.com/SurfsUp/WebTrack.htm)
2. Press [e] to skip to the first edit field and press [enter] to enter forms mode
3. Press [down arrow]. This selects from the list of saved addresses in Firefox. If I want the fourth saved address for example, press [down arrow] four times and then [enter] to select and populate the form.

Actual results:

JAWS does not read the selected autofill option

Expected results:

Prior to Firefox 91, JAWS would read the selected address with each press of [down arrow].

I reproduced the problem on a new profile and on a second Windows laptop running Firefox 91. I also brought this issue to the attention of Vispero customer support, who were able to reproduce the issue with JAWS , NVDA, and Windows Narrator in Firefox 91.

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[James Teh [:Jamie]]

[Tracking Requested - why for this release]: Completely broken form autofill for screen reader users.

Comment 3

[James Teh [:Jamie]]

9:15.80 INFO: Last good revision: f6fbf6487e6d80037dc4d1c70e5fb2fce10101ff
9:15.80 INFO: First bad revision: 229e905d571ebbe18c9d2e5a6fd1a9b654db6afb
9:15.80 INFO: Pushlog:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=f6fbf6487e6d80037dc4d1c70e5fb2fce10101ff&tochange=229e905d571ebbe18c9d2e5a6fd1a9b654db6afb

This implicates bug 1708735.

Comment 4

[James Teh [:Jamie]]

This broke previously and was fixed in bug 1566299. As per bug 1566299 comment 4, we have tests for this, but they've been disabled for years due to various problems. I think it's time to throw those tests away and just start over with a stripped down test so we can prevent this regressing again.

Comment 5

[James Teh [:Jamie]]

The problem is that the flattened parent fetched here is now a slot instead of the autocomplete popup panel. I don't quite understand how the slotting works here. Using GetParent() here instead "fixes" this, but is it the "correct" fix?

Comment 6

[Emilio Cobos Álvarez (:emilio)]

It's very sketchy that that code is relying on the DOM of the front-end for something like this. Anyhow, using GetParentElement() is the right fix if the listbox is a direct child of the relevant <panel>, yes.

Comment 7

[James Teh [:Jamie]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #6)

It's very sketchy that that code is relying on the DOM of the front-end for something like this.

Fair, but the alternative would be to try to make the XUL widgets do all of this with ARIA (instead of having C++ code handling the a11y)... and given that the input and the popup are in different documents, that's impossible, since ARIA attributes can't point to a node in a different document. Or I guess we could add some new interface on the richlistbox which allows you to retrieve its popup. Either way, that feels like refactoring work which isn't going to get done any time soon.

Comment 8

[James Teh [:Jamie]]

Attachment: Bug 1722621: Fix detection of autocomplete popups in XULListboxAccessible after recent DOM changes.

Previously, we used GetFlattenedTreeParent from the list box to find the autocomplete popup.
After bug 1708735, this now returns a slot instead of the panel.
We now use GetParentElement instead, which works as expected and is consistent with other code in this class anyway.

I also added a new test so this doesn't regress yet again.
We already have test_focus_autocomplete.xhtml which is supposed to test this, but that test is broken, was thus disabled and is complicated enough that I don't think we're going to fix it any time soon, if ever.

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/43d636e24bf6
Fix detection of autocomplete popups in XULListboxAccessible after recent DOM changes. r=morgan

Comment 10

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/43d636e24bf6

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta approval ASAP so we can get it uplifted for the RC.

Comment 12

[James Teh [:Jamie]]

Comment on attachment 9233651 [details]
Bug 1722621: Fix detection of autocomplete popups in XULListboxAccessible after recent DOM changes.

Beta/Release Uplift Approval Request

• User impact if declined: Form autofill will be completely unusable by screen reader users.
• Is this code covered by automated tests?: Yes
• 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, well isolated change covered by automated tests.
• String changes made/needed:

Comment 13

[Julien Cristau [:jcristau] (back April 22)]

Comment on attachment 9233651 [details]
Bug 1722621: Fix detection of autocomplete popups in XULListboxAccessible after recent DOM changes.

a11y regression fix, approved for 91 rc1

Comment 14

[Julien Cristau [:jcristau] (back April 22)]

https://hg.mozilla.org/releases/mozilla-beta/rev/41906587ccef