Bug 1686694 Comment 2 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

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.

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

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)
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)

Back to Bug 1686694 Comment 2