spun off from bug 28520. in the browser F6/shift+F6 cycles through frames. it'd be cool to also allow this key-combo to cycle through open panes in the mailnews window. unsure how this would work on Mac, though, since the function keys can often have other preset behaviors.

On Mac it will be Ctrl+tab/Ctrl+Shift+tab Please implement both for all platforms. That was the conclusion of the group of people who worked on the frame+pane keyboard navigation spec.

Where can I find the frame+pane keyboard navigation spec?

scott, the proposed keyboard map [long!] is at http://www.mozilla.org/projects/ui/accessibility/mozkeylist.html there's also "access bug radar" table which lists existing bugs in various areas: http://www.mozilla.org/projects/ui/accessibility/access-radar.html

spoke with bryner: just noticed that f6/shift+f6 currently only goes btwn the folder and message pane. this is because the folder and thread pane are considered one document from a frame-point-of-view.

probably the best and easiest way to do this would just be to override f6 and ctrl+tab in the mailnews xul.

reassigning to ssu. I have to admit, that I'm not a big fan of not using tab to move among the panes. Bug 78269 mentions another way of doing this which is more acceptable to me which is to have tab work as it does now and then when there is something in the message having tab move into the message. Personally I'd like tab to work as it does now and then have ctrl-tab bring you into the message. I'm cc'ing Jennifer for her thoughts on this.

I think Ctrl+tab to bring you into the message would be really inconsistent. I vote strongly against that. Tab will act as it does now for 90+% of messages that have neither links nor form elements. Ctrl+tab should work as it does throughout the entire app. In my opinion, we need as much consistency as possible throughout our app's UI.

Bug 78269 suggests using the Tab key to move from pane to pane and within each pane. So if the pane contains tab items (such as form elements in the message pane), those items are included in the tab order. Once the tab items within the pane have been cycled through, tab moves onto the next pane. Ctrl+Tab can be used to jump from pane to pane, skipping any tab items that might be contained within the pane.

jgclick: In bug 112380 I ask to bind at least the standard Windows shrtcuts Ctrl+F6/Ctrl+Shift+F6 to next/prev tab.

This patch will implement the following: * add the Quick Search pane to the cycle order. * (shift) Ctrl TAB - cycle thru panes ignoring form elements * (shift) Ctrl F6 - same as (shift) Ctrl TAB * (shift) F6 - same as (shift) Ctrl TAB * (shift) TAB - cycle thru panes. If form elements are encountered in a pane, then it will tab thru each (and all) of the form elements before going to the next pane. This patch will also fix bug 78269.

This patch combines and replaces the patch to 112577, as well as attachment 61983 [details] [diff] [review] above, additionally fixing bug 110177 (and bug 75269 of course). It also ensures that Quick Search is visible before switching to it, which was a bug in attachment 61983 [details] [diff] [review]. It also makes SwitchPaneFocus much more readable. It is also compatible with bug 105542.

Comment on attachment 62078 [details] [diff] [review] Propsed Patch found a couple of things: 1) change 'searchBox.getAttribute... to searchInput.getAttribute... 2) in mailWindowOverlay.xul, include the following to the tab/f6 focus code: <key keycode="VK_F6" oncommand="SwitchPaneFocus(event);" modifiers="control"/> <key keycode="VK_F6" oncommand="SwitchPaneFocus(event);" modifiers="control,shift"/>

oops. for 2), I meant to add the following (in addition to what you have): <key keycode="VK_F6" oncommand="SwitchPaneFocus(event);"/> <key keycode="VK_F6" oncommand="SwitchPaneFocus(event);" modifiers="shift"/>

Thanks for spotting those. Actually searchBox is searchInput.parentNode but the code was wrong anyway :-) Speaking of parentNode, I would like to point out that I wasn't keen on using focusedElement.parentNode.parentNode.getAttribute('id') because focusedElement is anonymous XBL content so I would suggest that that code isn't reliable. [Also IIRC .id is the same as .getAttribute('id')]

Picked up the old file again last time - sorry.

Neil, I found a problem with your earlier patch: 1) run mailnews 2) click on the searchInput box 3) click on 'View | Show/Hide | Search Bar' to hide the quick search area 4) click on any of the supported tab/f6 conbination keys. I noticed that it no longer works. Can you fix that to either: * automatically set the focus to the thread pane when the quick search area is hidden. * get tab/f6 keys to work in the case mentioned above.

I can't get tab/f6 keys to work in the case above because on my pc it kills the keyboard entirely. Since I can't fix the command dispatcher, or change goToggleToolbar to use "collapsed" instead of "hidden" (because it would break existing profiles) I have added a focus fixing function instead.

looks good to me. r=ssu

reassigning to myself to check in. Seeking sr= for neil's patch.

Comment on attachment 62508 [details] [diff] [review] Fix focus after setAttribute("hidden", "true") sr=mscott

patch checked in.

I transfer my comment from bug 78269 and re-open this one since sidebar is not included in the navigation. I can separate other issues in dif bugs. For instance for Alt 3-pane - some changes are going to be done there (bug 105542). 1. On Win: F6, or Ctrl+Tab, or Ctrl+F6 skips sidebar pane. 2. On Linux Ctrl+Tab switches between Desktops, not between our panes. 3. Alt 3-pane window has all these troubles. 4. Above keyboard combinations don't include 'Advanced' button (next to QuickSearch field) in the Tab order. When we use Tab, this button is included in the navigation, as expected.

1. I don't think there's a way to get to the sidebar. The browser window has the same problem, so we are okay. 2. hmmm... that's probably the desktop app overriding our controls. I'm not sure what to do about this one under linux. 3. as long as alt-3 pane exhibits the same behavior as the normal 3 pane, then I think we're okay. 4. the Advanced button not being part of the Ctrl-Tab, Ctrl-F6, and F6 keys is correct. That is the behavior we wanted. Only Tab will get to the Advanced button. This bug seems to be fixed for me. As for the problem under linux, if you are able to change the desktop keys from Ctrl-Tab to another key conbimation to switching between desktops, does Ctrl-Tab then work properly in mail news.

Aaron, what should we be using on Linux to navigate through the panes? Also, I think you mentioned work on the Sidebar in one of our meetings today. Will we get that for free when it gets fixed?

Scott, I don't think you'll get pane nav for free - the sidebar accessibility bugs that sgehani is fixing don't relate to pane navigation problems. If there are problems getting sidebar into the navigation cycle, bryner is probably the right person to ask for advice. As far as what keys to use, it actually should be the same for all 3 platforms. We have redundant sets of keys, because on some platforms (especially Linux/UNIX), the window manager may steal one of the choices (for example for switching desktops). I've noticed that KDE steals Ctrl+[shift]+Tab for that. In addition, both sets of keys are standard in MS Windows. Therefore, Ctrl+[shift]+tab and [shift]+F6 should both cycle through the panes.

Great, we are almost there. Brian, do we have a bug for sidebar accessibility?

or I can log a bug that sidebar is skipped when navigate by keyboard. Then close this one! In this case, someone, please change it to Fixed.

closing this one as fixed again.

Verified. For Sidebar and Advanced button only Tab navigation.