Closed Bug 1722621 Opened 3 months ago Closed 3 months ago

Screen readers not reading Firefox autofill options

Categories

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

Firefox 91
defect

Tracking

()

RESOLVED FIXED
92 Branch
Tracking Status
firefox-esr78 --- unaffected
firefox90 --- unaffected
firefox91 + fixed
firefox92 --- fixed

People

(Reporter: acawai, Assigned: Jamie)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

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.

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.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

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

Severity: -- → S2
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Priority: -- → P1

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.

Regressed by: 1708735

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.

See Also: → 1566299

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?

Flags: needinfo?(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.

Flags: needinfo?(emilio)

(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.

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.

Assignee: nobody → jteh
Status: NEW → ASSIGNED
Pushed by mreschenberg@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/43d636e24bf6
Fix detection of autocomplete popups in XULListboxAccessible after recent DOM changes. r=morgan
Regressions: 1723230
Status: ASSIGNED → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch

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

Flags: needinfo?(jteh)
Flags: in-testsuite+

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:
Flags: needinfo?(jteh)
Attachment #9233651 - Flags: approval-mozilla-beta?

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

Attachment #9233651 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
You need to log in before you can comment on or make changes to this bug.