IIRC, this used to work, but now it does nothing, differently from the Library and the hamburger menus that support it.

There are three regressions.
#1 focus ring is no longer indicated for whole row(or left column) of list, but It has focus.
#2 focus ring is no longer indicated for whole row(or left column), right column of list and footer, but It has focus.
#3 No longer focus left column of list(other than 1st row), so I cannot open downloaded file. And focus ring is no longer indicated for right column of list and footer, but It has focus.

#1 regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=79197e2d630ab38e53971c7e9a5b028940a05b63&tochange=9849ea3937e2e7c97f79b1d2b601f956181b4629

Suspect: ba0ea459e2226f0ecc91f199809d5abb6a80de48 Paolo Amadini — Bug 1473521 - Load "richlistbox.css" as a document stylesheet. r=bgrins

#2 regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=4e6486b672b32aba075b704c6b1e41e8ccf7a135&tochange=3f362dfcc16039bd81c171d039e39f3cbf64d003
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a3140755de6987e9e383f128a5e56386a6da0b09&tochange=3f362dfcc16039bd81c171d039e39f3cbf64d003

Suspect: ?

#3 regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d58b6e90927f9dd762717179c547276024a624bc&tochange=54cb6a2f028b033ef567f00af2f82f5fb97ab437

Suspect: 2614ca0a8884a2995a59d07a59340d412450e4f2 Paolo Amadini — Bug 1452626 - Remove the "download" binding. r=mak,bgrins

Thank you, there are indeed various reasons for which this is broken and it's not so trivial to fix it.

First, this define is wrong:
https://searchfox.org/mozilla-central/rev/2a24205479519e70c0574929f45730d285141584/browser/themes/shared/downloads/downloads.inc.css#12
#downloadsListBox:focus > @item@[selected]
becomes
#downloadsListBox:focus > #downloadsListBox > richlistitem[selected]
that is clearly bogus.

The keypress and keydown handlers that downloads.js add don't use mozSystemGroup, as such they are not invoked for navigation keys. Actually the keypress one is not invoked regardless. IIRC we changed keypress to be more Web compatible some time ago and we may have to switch to keydown. (bug 968056)

The worst issue is that I can't have the richlistbox take focus, it looks like the only thing that can take focus in the panel is the footer button. so the :focus css selector is never satisfied, and key events are always sent to the button.

The keyboard navigation style that we choose (focus ring) is also not coherent with the other toolbar panels that just move selection. The best path may be to rewrite from scratch the keyboard navigation in the panel. But we could also go with an initial brokeness fix and file a separate bug for the styling.

Neil, any idea why invoking focus() on the richlistbox in this panel seems to be ignored? document.activeElement seems to always be "downloadsFooterButtons". (I downloaded the 5MB test file from thinkbroadband multiple times, that actually fails in nightly due to mixed content, but still populate the list)

My patch restores keyboard navigation in shape of focus rings and only on buttons. In practice up/down/tab already allow to move focus through the panel buttons, the patch just makes that visible and sets the richlistbox selection accordingly.
It is not the same selection style as the other panels, but it should do until the work on the downloads experience kicks-off.

It sounds like my previous question is not exactly correct, buttons in the panel can become the activeElement, it looks like in the past it was also possible to focus the RLB, but now it's not. Probably it doesn't matter much, the default action is still executed by activating buttons, and the contextual menu can still work for the other actions.

This still needs some kind of test checking the active element and the richlistbox selection, hopefully I can find some time for that in the next days.

not actively working on it now, my patch could be used as a starting point.