Status

()

For bugs in Firefox Desktop, the Mozilla Foundation's web browser. For Firefox user interface issues in menus, bookmarks, location bar, and preferences. Many Firefox bugs will either be filed here or in the Core product. Bugs for developer tools (F12) should be filed in the DevTools product. (more info)

This doesn't seem to be a dupe, so confirming.
If we want Firefox to be accessible to those who can't use the mouse, this is
definitely needed. I'm nominating F9 as a Close Siderbar button (don't confuse
this with Bug 184565 which suggested F9 as both Close *and Open* Sidebar button).
Prog.

Rather than futzing with global keyboard shortcuts, I recommend we simply add the sidebar close button to the tab order, so the user can tab to it and press ENTER to close the sidebar. Patch tested with Inspect32 and WindowEyes 5.5 on Windows; close button is exposed as role=pushbutton, name="Close sidebar" (localized) and read correctly by WindowEyes.

The patch seems to have rotted (on branch, at least) a little bit. I hacked the CSS manually, though, and didn't see the effect (on Mac). But maybe we should be supporting the close tab (Accel-W) shortcut in the sidebar instead of tabbing over to the closebutton? Otherwise you get this weird effect where you've got the sidebar in focus (with a focus rect!) and Accel-W closes the tab that's *not* currently given focus.

Re-diffed against latest trunk.
I disagree with Beltzner that changing the behavior of Accel-W is the appropriate solution for this bug. The behavior you describe already exists (lots of sidebars can have focused elements, but Accel-W still closes the unfocused browser tab), but this patch doesn't make that inconsistent behavior any worse.
And yeah, you won't see the focus rectangle on Mac OS X. Test on Windows or Linux or some other platform that shows focus rectangles on random things.