1628255 - about:downloads and the Downloads page in the Library window no longer speak the name of downloaded files

Status: VERIFIED FIXED

(Firefox :: Bookmarks & History, defect, P1)

Description

[Marco Zehe (:MarcoZ)]

A very recent regression, probably bug 1608202.

STR:

1. Download something.
2. Open either about:downloads, or the Downloads page in the Library window by pressing CTRL+J.
3. Open Dev Tools, the Browser Toolbox, and Accessibility Inspector. Turn on the engine and inspect the accessible name for each richlistitem in the panel.
   • Expected: The name of the list item should be the file name, followed by the size and download source, as before.
   • Actual: All items only have an accessible name of "Open target folder". This corresponds to the name of the button that is also included in the list item children.

There is probably an aria-label or aria-labelledby override somewhere that only grabs the name of the button, but not the actual file info.

This makes it impossible for screen reader users to efficiently navigate the files they downloaded. Access-p1 for this, since it is a regression that seriously breaks functionality.

Comment 1

[tapper82]

I can reproduce this bug. Windows 10 firefox 77 nvda screen reader.

Comment 2

[James Teh [:Jamie]]

This occurs because the "open containing folder" button now has a label attribute which it didn't previously have. That causes a XUL label element to be created. That means that the richlistitem implementation of nsIDOMXULSelectControlItemElement::label, which concatenates the values of any label children, returns just this new label, since it's the only label. That overrides the a11y engine's fallback of calculating the name from subtree, which is what we used to do (and what we really want here).

Gijs, you noted that this label is invisible. Do we really need it in that case if we didn't have it before? (Presumably, we still have tooltiptext?) Obviously, the fact that the label attribute breaks things here is far from ideal. However, it's unclear to me exactly what the right fix is here. I'd need to dig back through history to figure out why we have this nsIDOMXULSelectControlItemElement::label implementation at all.

Comment 3

[James Teh [:Jamie]]

This is not the first time this nsIDOMXULSelectControlItemElement::label property has caused obscure, difficult-to-diagnose weirdness. See bug 1568453, where Morgan ended up removing an override of this to fix the bug.

Comment 4

[:Gijs (he/him)]

Attachment: Bug 1628255 - do not add a label/accesskey attribute to the button in the about:downloads and library downloads views, r?mconley!,flod!

As noted by Jamie, accessible labels for richlistitem elements come from the
label elements that have value attributes within them.

In bug 1608202, we accidentally reused the same fluent message for the buttons
in about:downloads and the library download view (DownloadsViewUI.jsm) and
the context menuitems that do the same thing. This meant that
those menuitems gained a tooltip they shouldn't have, and the buttons gained
a label and accesskey they shouldn't have. The latter caused the
accessibility regression described in the bug.

This patch separates out the two usecases for the same string. I also checked
the other l10nIds used in DownloadsViewUI.jsm, and as far as I can tell this
is the only one that is reused in this way.

Comment 5

[:Gijs (he/him)]

Marco, can you doublecheck the issue is resolved for you on the build from https://treeherder.mozilla.org/#/jobs?repo=try&revision=bdf201517f2b84f6a2637785b5baa0827de6cc2f ?

Comment 6

[Marco Zehe (:MarcoZ)]

This works as intended. Thank you!

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9e08318148ef
do not add a label/accesskey attribute to the button in the about:downloads and library downloads views, r=mconley,flod,fluent-reviewers

Comment 8

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/9e08318148ef

Comment 9

[Bogdan Maris, Desktop QA]

Verified fixed as part of PI 551; tested with Nightly 77 across platforms (Windows 10, macOS 10.15 and Ubuntu 18.04).