102711 - implement F6/shift+F6 and Ctrl+(shift)+tab to cycle through panes in mailnews window

Status: VERIFIED FIXED

(SeaMonkey :: MailNews: Message Display, defect, P2)

Description

[sairuh (rarely reading bugmail)]

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.

Comment 1

[Aaron Leventhal]

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.

Comment 2

[scottputterman]

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

Comment 3

[sairuh (rarely reading bugmail)]

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

Comment 4

[sairuh (rarely reading bugmail)]

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.

Comment 5

[Brian Ryner (not reading)]

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

Comment 6

[scottputterman]

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.

Comment 7

[Aaron Leventhal]

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.

Comment 8

[jglick]

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. 

Comment 9

[Olivier Mengué]

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

Comment 10

[Sean Su]

Attachment: patch v1.0

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.

Comment 11

[[e-mail]]

Attachment: Propsed Patch

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 12

[Sean Su]

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

Comment 13

[Sean Su]

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

Comment 14

[[e-mail]]

Attachment: Fix ssu's catches

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

Comment 15

[[e-mail]]

Attachment: Correct fix for ssu's catches

Picked up the old file again last time - sorry.

Comment 16

[[e-mail]]

Attachment: Updated because patch to bug 112577 got checked in

Comment 17

[[e-mail]]

Attachment: Updated because bug 112577 got checked in properly

Comment 18

[Sean Su]

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.

Comment 19

[[e-mail]]

Attachment: Fix focus after setAttribute("hidden", "true")

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.

Comment 20

[Sean Su]

looks good to me.  r=ssu

Comment 21

[Sean Su]

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

Comment 22

[Scott MacGregor]

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

sr=mscott

Comment 23

[Sean Su]

patch checked in.

Comment 24

[Olga]

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.

Comment 25

[Sean Su]

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.

Comment 26

[scottputterman]

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?

Comment 27

[Aaron Leventhal]

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.

Comment 28

[Olga]

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

Comment 29

[Olga]

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.

Comment 30

[Sean Su]

closing this one as fixed again.

Comment 31

[Olga]

Verified. For Sidebar and Advanced button only Tab navigation.