The user should be able to navigate the mailnews window by keyboard alone. In particular, it should be possible to switch between folder, thread, and message pane with the keyboard (Ctrl-Tab maybe?) and change selections in folder and thread pane using the keyboard. The latter works already with Up and Down. In the thread pane, it would be good to navigate faster as well, for large mailboxes. For this, PgUp and PgDn could scroll by the number of headers in the thread pane. Also need keyboard shortcuts for Next, Previous, Next Unread, Previous Unread, etc.

Reassign to hangas. I vote for TAB to switch focus between panes, which is what 4.x does.

The Browser intends to handle this problem by using CTRL+Tab to cycle through the areas. URL Bar, and Web Page so far maybe sidebar. Previously it was done by tabbing through every thing till you cycled back. We should get together to ensure that the methods used are the same especially now that we need to include sidebar.

Jennifer/German any comment here? I personally think tab should move us from field to field, and when we reach the last field move to a new pane. Some panes (like folder and thread) do not have any widgets so tab would just move the next pane; the message pane might have html form widgets so in that case tab should move from widget to widget. The only case I am not sure of is the case where we have tabbed to the message pane and it has html form widgets. Should we have focus on the first of those or none yet? If we don't automatically focus, then should the next tab move us to the next pane or to the first widget? If we decide (from above) that tab should focus on the first widget when we tab into a pane, then I think Ctrl-Tab to move from pane to pane without stopping at the sub-widgets within the pane would be a great addition to the product.

cc'ing Lake since she has been working on accessibility issues.

The browser wil set the focus to the first item regardless of the area since the frame has no fuction to invoke with out the widget inside. If you use the Ctrl+Tab to jump areas/panes then once you reach html content in a message area giving the first item focus allows you to use tab to continue throught items or Ctrl+tab to move on to the next area. This would be consistent behavior with the browser. If you don't give the first item focus I wonder how you keyboard through the message area content with out using the mouse. What do ya think?

OK, I am in favor of selecting the first widget in a pane when we tab there (if there is one), then tab will take us to the next widget (if there is one), and when there are no more widgets tab will take us to the next pane. If no objections then I will attempt to implement this. On the issue of Ctrl-Tab, what would the key be for Mac and Linux? I am not sure what the choice would be. Ctrl-Tab on my Mac switches me from one application to the next.

Oh, and Command-Tab on the Mac forces Netscape 4.72 to tab out of a text field that normally allows tabs as a character.

A link to Lake's Keyboard Navigation spec: http://gooey/client/5.0/specs/keyboard/kybdnav2.htm

Mass moving to M16 to get these off the M15 radar. Please let me know if this is really an M15 stopper.

Scott, clearing Hangas' plate for skins work. Probably need to reassign some of these again.

moving to M18.

moving to future milestone.

Need to have keyboard acess to all parts of Mail.

+, P3 per mail triage to have tab and ctrl+tab functional for the panes in the 3pane mail window. Note: when testing, need to test alternate 3pane view.

reassigning to varada

P1 per mail triage

To PDT: This bug is a P1 because of feedback from usability for keyboard users.

PDT thinks this is P2 at best, if this is a top takeaway from usability feedback. Left to our own, we'd prioritize it lower.

Marking Fixed. Tab and Shift Tab will focus on the consecutive mailpanes clockwise and anticlockwise respectively.

Build 2000-09-12-08M18: NT4, Linux 6.0, Mac 9.04 Reopening or I can log a new bug. Tab and Shift+Tab is working but when I login to mail: * The Inbox is selected but I don't see a Focus Ring in the folder pane and the navigation keys don't work. If I select the Inbox with the mouse the Focus Ring still doesn't appear. I have to use the mouse and select another folder for the Focus Ring to appear. Then the navigation keys work. * Tab to the thread pane and no message is selected. I have to use the mouse to select a message, now all the navigation keys work. - With a message selected tab to the message pane and the navigation keys work. - Tab into the folder pane and the nagivation keys still work - Tab into the thread pane, a message is selected and the navigations keys still work Expected Results: When logging into an account it should: - Automatically display the Focus Ring in the folder pane and the navigation keys should work. - Tabbing from the folder pane to the thread pane should automatically highlight a message and the navigation keys should work.

we should close this bug and open a new one. Tabbing from pane to pane works fine. We aren't going to select a message for the user automatically. They can use "F" to pick the first one or "N" to pick the first unread. I'm going to mark as fixed again.

So, is it a new bug that you can't tab into the Sidebar panel in mail? And that if you click in the AIM tree view, the focus outline stays in the last focused mail pane? > Expected Results: When logging into an account it should: > - Automatically display the Focus Ring in the folder pane and the navigation > keys should work. Not sure I agree with that. I think since a folder is selected, the input focus should be in the thread pane. If a message were selected (and I understand we're not doing that), the input focus should be in the message pane.

It probably is a bug that we don't tab into the sidebar, but I don't think that's worth fixing for this release. As for the focus rect sticking around when in the sidebar, my understanding is that Andrew has the fix for this. Note, this bug was for tabbing, Andrew has a separate bug dealing with the focus rect. However, for other testing purposes, I'm not sure if what was checked in handles the case where the sidebar or the thread pane are collapsed. I think it still might try to go to them. We'd have to try that out.

One other thing. I tried this out earlier today after reading Ninoschka's comments, and it looks like focus is starting off in the Message pane which is why she's seeing the results she saw. Tabbing once brought it to the folder pane and everything worked. I didn't have to click anywhere to start being able to tab. With the focus rect working now (soon to work in the alternate 3pane window), it makes it much easier to see these things.

When you say we are not going to select a message do you mean that we are not going to do it now or that you are not going to do it ever? Because as it stands the user experience is broken for the user. They can not use the arrow keys which are the most obvious and accessable keys for this. Additionally, it should save state at least with in a session. So if you go to another folder and come back the same one should be selected and that item should load to the message pane then when the user hits an arrow key it should work. And yes the sidebar not being in the tab cycle is a bug for every app. I'll see if it has been filed it might be covered by the no key board access to the Sidebar bug 48251. My last comment was "At the very least the open sidebar panel should be included in the Tab cycle. The items in the open panel should work like a web page."

We aren't selecting a message in this release. Perhaps some day in the future we will fix this. We have other bugs on this. Once they learn that they can hit "F" or "N" they will be set. I'm sure there are lots of other experiences in our product that are bigger than this that will seem broken to our users, as well. Once Varada makes the enter key work in the thread pane, I think we've done enough for keyboard navigation in this release. As I said, tabbing to the sidebar is nice, but I really don't think that whatever percentage of users who don't use a mouse in mail, are going to be devastated that they can't tab into the sidebar in mail in this release. I would imagine that the first priority is to to tab between mail panes.

I quite agree with you for preview release 3 only on the sidebar but am not sold entirely on the F and N area. :-) Your assumption is that users will find this but in my experience they are not likely to. Certianly not a P1 or P2 but if we could consider for if we have time type of fix rather than a definite later I would be understanding.

- There is a problem with IMAP accounts. Login to an IMAP account, the Message pane has focus. Press the Tab key and the Focus Ring doesn't change. I then selected the up and down arrow keys to see if focus is actually in the folder pane but nothing happens. If I select the folder pane or the thread pane with the mouse then the Tab key works and the up and down arrow keys also work. Varada is looking into this. - Close the Message pane and Tabbing still cycles through all the panes. With the thread pane selected, select the Tab key and nothing appears in focus. The up and down arrow keys do nothing. Select Tab again and the folder pane is in focus and the down/up arrow keys move to different folders. Closing the Sidebar is ok. The tab key only cycles through the folder, thread and message pane. - I agree that the Thread pane should have focus by default. Varada said that he can do this.

I'm willing to reopen to get the starting scenario correct and to make sure tabbing works correctly when various panes are closed.

OK this is how it should work. On opening Mail for the first time they should have at least one account because of the setup stuff so on opening they should have something in the folders pane. Remember the web page loads in the message area on starting Mail. Not very intuitive so unless some one could auto move focus to the Folders Pane after loading the Web page or in some instances failure to load, we are stuck with this. The first tab stroke should take them from the message pane (unless we fix some other things) to the folders pane with the top accounts' Inbox selected. Do not select the Account since nothing shows up there and you can't actually do any thing with it. The users in the usability studies had a big problem with this. From here they can then either log on or arrow up and down the folders. Once a folder is selected and it's messages loaded, another tab will take the focus to the thread pane where and the newest message down loaded should be the message selected. The reasoning is: If they are online they are likely to want their messages so loging on first will do that then though they may or may not be particullarly interested in this message it is more likely they will want it than any randon one and if they don't are more likely to be in the area where it will take them fewer keystrokes to get to the messages they want. Also a majority of our typical users do their mail online. Starting mail in general should work the same way. Now if they are returning to the window every thing should be as it was before they left. Now what we are seeing may be that the message folder tree gets the focus event rather than the pane. So focus would seem to move between the message pane and folders but not the folders. And then since nothing is selected in the folders you get no response from the arrow keys. In short it looks broken. The Ctrl+Tab and keyboard acess to the address links/pulldowns and any attachment buttons there. Even if the tab is generally working Keyboard access as a whole for Mail is not even close to fixed.

Proposed Fix When mail is opened the focus is on the ThreadPane Using the down arrow in the ThreadPane will jump to the first message. Tabbing will be within "open" panes.

I have the fix in hand but it also involves a very trivial fix for bug#53253. I am adding the dependancy and marking it P2.

All three navigation fixes are checked in. Opening with focus on threadpane, Using down arrow to jump to first message while focus is in threadpane, tabbing only in open panes.

Reopening Trunk build 2000-09-25-09M18 on NT4 Will check the Branch build when it's available today. The thread pane has focus and the up and down arrow keys work but - tab into the message pane and it's difficult to tell if the message pane has focus. The up and down arrow keys are not working in the message pane - tab into the folder pane and the same problems occur

Additional Information using the 9/25 trunk build: If the default account is: - POP then the thread pane has focus, the up and down arrow keys work. Then tab into the message pane or folder pane and it doesn't appear that the other panes have focus and the up and down arrow keys don't work. - IMAP then it doesn't appear then any item has focus and the up and down arrow keys don't work at all.

Adding rtm to keywords and adding dependancy on saari's focus bug #53861

rtm+, this is central to the key nav story we _had_ working for a couple days...

Not holding PR3 for this, so marking nsbeta3-

changing to [rtm need info]. We want to rtm+ this but need a patch and code reviews. When those exist, please change back to [rtm+].

What is not working specifically here. This seems to wfm on windows.

the magic fix must have been checked in because it's working on my windows build too. Can someone verify this on all platforms?

I am not able to tab using the oct 02 build on windows( nor on my PR3 builds)!!!

It worked on my PR3 build at work and on my debug build from 10/2 at home. I wonder why you can't see it.

On all platforms using the branch builds from 9/29, I'm able to tab through the 3 panes. I also tried a linux trunk build on 10/3 and was also able to tab through the panes.

I'm going to mark WFM. everything seems to work.

Branch build 2000-10-07-09MN6: NT4, Linux 6.0, Mac 9.04 Reopening There seem to be some focus problems 1. Can't navigate after logging into mail: Windows only problem (OK on Linux and Mac) - When opening an account enter the password in the login dialog, ok. - Try "N" to go to the next message or the up/down arrow key and nothing happens - I must select an area on the window with the mouse then the navigation keys work. - Also noticed if Password Manager is used then the navigation keys work. There is something about the login dialog that seems to cause the problem. 2. Shift+Tab: Loses focus a. With a message in the thread pane selected, Shift+Tab. No focus in the folder pane, can't use up and down arrow keys. b. With a folder selected in the folder pane, Shift+Tab. No focus in the message pane, can't use up and down arrow keys. c. Yet it Does work if the message pane is selected. Shift+Tab moves focus to the thread pane and the up and down arrow keys Do work.

rtm-, seems like it's time to let this one go. The remaining symptoms don't seem severe enough to win pdt approval.

Branch build 2000-10-12-09MN6: NT4 Tried again with this build and the focus problems remain.

sorry for the extra email. Removing mail2 keyword.

Build 2001-04-09-04: NT4 I've noticed in recent builds that I can tab to different panes. The problem occurs in the Message pane when using the down arrow, it does not scroll down/up the contents of the message.

An FCC Section 508 requirement - adding fcc508 keyword. This must be fixed before Mozilla based products can legally be sold to the US Federal government.

The message pane scrolls for me now. Was there more we had to do to mark this fixed?

This is not quite fixed, although we might want to open a new bug. Here's what's wrong: 1. If the message has links or form elements in it, tab/shift+tab need to walk into the message, so the user has keyboard access to all of the interactive elements in the message. 2. The frame+pane navigation keys Ctrl+(shift)+tab, alternatively (shift)+F6, should do what tab does now - navigate only through the open panes.

bug 78269 addresses keyboard access to form elements in a mail message. filed bug 102711 to implement f6/shift+f6 to go through panes in the mailnews window.

I'm going to mark this a dup then of 78269 *** This bug has been marked as a duplicate of 78269 ***

Verified duplicate.