No idea who to assign this one to... In 4.x I can use the Ctrl+Tab key combination to quickly change to the next Netscape window, be it a browser, messenger, composer window. I can't do this in Mozilla. To replicate: 1. open more than browser window 2. press Ctrl+Tab a few times Expected Results: the open browser windows are cycled through Actual Results: nothing happens Would this be 4xp? Build ID: 2000030516 Platform: NT4 sp6a

Dupe of Bug 9701 - at least, I assume it is if this bug can be described as: "nsWebShell Key events not working until focus set in window (TAB, PgDn, ALT+, CTRL+)" (I am assuming CTRL+ means Ctrl plus either TAB, PgUp or PgDn.) Gerv *** This bug has been marked as a duplicate of 9701 ***

This has nothing to do with bug 9701. Open up two windows in NS 4.x and press Ctrl+Tab. You'll switch between the two windows. That's what I'm talking about. Re-opening this bug.

<rereads bug 9701 at length> Ah, now I understand. Apologies. Yes, this is fairly serious, isn't it? This is so obvious, though, that it's incredible that no-one's noticed it before... I can't find a dupe, and this will surely generate a load of bug reports if it makes it into the beta, so... Confirming, changing severity to critical and nominating dogfood (I hope I'm allowed to do that!) Gerv

Sending to XP Toolkit for a look. Not critical as no data is lost, probably not going to get a PDT+ as it isn't really necessary functionality for day to day browsing.

I agree, it should not be marked dogfood. It is not major severity either, since there is no loss of function. You can still switch between windows, there is just no keystroke for it. assigning to danm as p4 for m16

More of a key binding, event thing. Chris?

Putting on PDT- radar for beta1. Will release note.

The use of ctrl+tab to move among the set of Mozilla windows collides with two other usages, one proposed, the other actual. CC-ing lake@netscape.com In bug 19446, lake@netscape.com on 1999-11-30 suggested the use of ctrl+tab to move focus from frame to frame to URL bar and so on, although this was not finalized. According to masri@nolex.com and mpt@mailandnews.com on 2000-02-27 in bug 29086, "Tabbing within TEXTAREA removes focus from text field", ctrl+tab (command+tab) cycles through currently running programs in MacOS 8 and MacOS 9, much like alt+tab does on Win32, so this may not be useable as an intra-application switcher on Macs.

We need to keep the functionality for switching between windows and we really should have the ability to move from area to area (URL, Web Page, SideBar etc.) I don't have a pat solution now but I am willing to work on the UI and Spec it with the engineers implimenting it.

If anyone wants it, I have a proposed spec written up for using Tab with various modifier keys for various purposes (including cycling through windows).

mpt@mailandnews.com: please do make your proposal available. It seems to me that ctrl+tab (command+tab) could be overloaded the same way that [PgUp]/[PgDn] are within a <TEXTAREA>, exiting the textarea when focus is within it (as proposed in bug 29086), and everywhere else cycling through windows, leaving perhaps shift+ctrl+tab for moving from area to area (in one direction only)... anything you've written up carefully will be worth reading.

Ok, proposal's up. See URL -- best viewed in Mozilla, since it uses complex tables and CSS2 for readability. Highly unfinished, but the section on the Tab key is there. The edited highlights, as far as this bug is concerned: * There would be no key combination in my proposal for cycling between Mozilla windows, except on Mac. Reasoning: Windows and X (the large majority of X window managers, anyway) both already have Alt+Tab and Shift+Alt+Tab to cycle between windows. An application-centric window switching keyboard combination is not necessary or desirable. If I have Navigator, Messenger, and Outlook Express windows all open, why should there be a special keyboard shortcut for switching from the Navigator window to the Messenger window and back again, rather than just using the OS's global keyboard shortcut for switching through *all* open windows? That Navigator and Messenger are part of the same app -- or even that the eBay and Hotmail Web applications are being displayed by the same app -- Should Not Matter to the user. So, Mozilla windows shouldn't be any more related to each other (with a keyboard shortcut) than Mozilla windows are related to the windows of any other app. * On MacOS, Option+Tab would be used to cycle between Mozilla windows, to compensate for the lack of an OS-global window switching keyboard shortcut -- it would complement MacOS's global Cmd+Tab shortcut for switching between apps. So no matter what window you were in, you could get to a particular Mozilla window using only the keyboard, just like you could on Windows or X. * Ctrl+Tab would cycle between frames (if any), tabsets (if any), and text widgets in toolbars (if any). It would also cycle out of (but not into) multi-line text widgets (see bug 29086). Example: I have the sidebar and location bar both open in Navigator. The cursor is currently in a multi-line text field. Pressing Ctrl+Tab repeatedly would have the following effect: * multi-line text field --> next link/widget * link/widget --> location bar * location bar --> sidebar * sidebar --> content * content --> location bar * location bar --> sidebar * sidebar --> content etc. Example 2: I'm in Composer, with the sidebar closed. Pressing Ctrl+Tab repeatedly would have the following effect: * content --> view mode tabs (for selection using cursor keys and Space) * view mode tabs --> content etc. Example 3: I'm in the body part of a message composition window. Pressing Ctrl+Tab repeatedly would have the following effect: * body --> addressing area * addressing area --> subject line * subject line --> body etc. * Ctrl+Shift+Tab would do the same thing as Ctrl+Tab, but in reverse order. Reasoning: Where a key combination involving Tab is used for navigation, Shift+ the same key combination should *always* perform the reverse navigation, and not be assigned to a different command. This is well established with existing uses of Tab for navigation on all major platforms. The net result of this proposal is that on Windows and X, Tab, Ctrl+Tab, and Alt+Tab form a linear pattern on the keyboard of navigation between small to large elements. And on MacOS, Tab, Ctrl+Tab, Option+Tab, and Cmd+Tab also form a linear pattern on the keyboard of navigation between small to large elements. Which is quite elegant, IMNSHO. This proposal provides suggested solutions for bug 30864 (this bug), bug 20986 (which has an evil twin in bug 18934), and I've even thrown in a solution for bug 31232 for free. Comments welcome.

Oh, and did I mention that the proposal also provides an implementation suggestion for bug 19446? :-)

I couldn't find the reference to bug 19446 in there. Also, what's the reasoning for moving away from the now pretty much standard shortcut of Alt+left/right for back and forward?

Generally I like your proposal there are just a few things that need to be worked out: So for the Windows OS currently: Alt+Tab = cycle through applications, Ctrl+Tab = cycles through open widows of the current active application, windows button+Tab = cycles through open windows in a nonapplication specific way. That said: I really hesitate to go against this. Thought I do like the simplicity of the Ctrl+Tab solution. And I generally agree that getting sidebar access is of rival importiance to within application window switching. Additionally, I question the usability of having "Tab" enter tabspace in a multi-line text field rather than moving focus. We need to keep the navigation simple and strong for Tab behavior. But that's another bug. It really only effects the part where Ctrl+Tab takes you out of a multiline text field. Another small point: though I agree in general principle that the order top to bottom left to right is a good thing I think in the case of the browser the order of most use would be URL - Content - Sidebar. Though For Mail it would run Folders - message headers - message test - sidebar. Entering Tabs in multi line fields is a lower priority for users and nearly an edge case for most web use. (Bugzilla is not a good example of a typical web page nore are we typical users) It takes a while for Specs to be posted so I'll let you know when the browser keyboard spec is avaliable. Should be in a few days. PS did you notice that Shift+Ctrl+Tab in the current 4.X jumps from Item in web page to URL to previous item. Wieerd. I don't think we want to duplicate that.

"PS did you notice that Shift+Ctrl+Tab in the current 4.X jumps from Item in web page to URL to previous item. Wieerd. I don't think we want to duplicate that." Not as long as bug 19446 gets addressed. As weird as the Ctrl+Shift+Tab shortcut seems, I use it all the time to quickly jump to the location field.

> So for the Windows OS currently: Alt+Tab = cycle through applications, Ctrl+Tab > = cycles through open widows of the current active application, windows > button+Tab = cycles through open windows in a nonapplication specific way. Unless it's been changed in Windows 2000, I don't think this is correct. Windows 3.1, 95, and 98 all use Alt+Tab to switch between all windows, not to switch between apps. The only platform which has an app-switching key combination is MacOS. Which is why I suggest augmenting that with Option+Tab to switch between Mozilla windows on MacOS. And Ctrl+Tab only cycles between windows of the current app if the application has implemented it that way -- otherwise this bug would never have been reported. And as I said, I don't think a Mozilla-centric window cycling keyboard combination is either necessary or desirable (except on MacOS). dean: the solution to bug 19446 is to press Ctrl+Tab (or Ctrl+Shift+Tab) to get to the location bar. That would even be backwards compatible (!) with 4.x's Ctrl+Shift+Tab -- though depending on where the focus was, if the sidebar was open you might have to type it twice instead of once.

My first reaction to all of this is contrafactual: I wish keyboards had one more modifier key! Now that that's out of my system... The unfortunate fact is that on Win32, the ALT+TAB cycling and the CTRL+TAB cycling are *completely* different beasts. First, some terminology: ALT+TAB+TAB means 'hold down the alt, press tab twice, let up the alt; ALT+TAB means 'hold down the alt, press tab once, let up the alt; ALT+TAB+... means 'hold down the alt, press tab some arbritrary number of times, let up the alt. The same applies to CTRL+. Second, some prehistory: prior to Netscape Navigator, all MS-Windows apps that allowed multiple documents to be open at the same time used the 'Multiple Document Interface' wherein each document was in a seperate sub-window in the App window, and CTRL-TAB was defined as the key to cycle through the documents. The modern apps I have tried cycle in one of two ways: either CTRL+TAB+... cycles in reverse order of document opening, or stackwise, in order of most recent use. In the web world, Opera works this way. The exception, MS-Word, used CTRL+TAB to insert a tab character into a table cell; a bare tab moved to the next cell. In that era, ALT+TAB+... could only switch between applications; no app maintained multiple top-tier windows. ALT+TAB+... has always worked stackwise: ALT+TAB+TAB returns the user to the second-most recently used app window, and ALT+TAB returns to the app window most recently used. Navigator introduced the idea of a single executable having multiple full- fledged application windows, each of which could independently be part of the ALT+TAB+... sequence. The Win95 interface did the same for Explorer windows. IE, and now MS Office 2000, have followed suit. In Navigator 2, 3, 4, 4.72, on MS-Windows, CTRL+TAB+... has always done something different from what the user would expect from any other application. Rather than cycling between documents in reverse order of opening, or stackwise, either of which is reasonably likely to return to a recently used document, Navigator cycles between documents in the order that they were opened. That means that if the user opens a document in a new window, and there are more than two windows, CTRL+TAB will go to the oldest remaining document window, not the last-used or last-opened document window. From a usability perspective, that is just plain wrong. Almost certainly CTRL+TAB will not go to the desired document, and if there are more than a handful of document windows open, CTRL+TAB+... will take more keypresses, and an indeterminate number, to return to the last-used document window, which compares very badly to a stack-wise implementation. CTRL+SHIFT-TAB+SHIFT-TAB cycles in reverse order of document window opening. If CTRL+TAB+... had a sensible stack-wise implementation implementation in 4xp, it would be almost completely surplufluous on Win32; the ALT+TAB+... sequence might well include windows from other apps, but CTRL+TAB+... would add no new functionality. But as it is, CTRL+TAB+... does something completely different. Personally, I never use CTRL+TAB+... with Navigator because ALT+TAB+ gets me back to the documents I am switching among in a natural way (plus it lets me switch between apps in a natural way), and CTRL+TAB doesn't. So to me it would be no loss if CTRL+TAB and CTRL+SHIFT-TAB were used for another purpose entirely. But, and here I'm playing Devil's Advocate, almost certainly some depend on the distinct order-of-document-opening CTRL+TAB+... cycling, having used and gotten quite familiar with how it works. As an aside, for those who may not have seen it, on Win32 both ALT+TAB and ALT+SHIFT-TAB bring up a window showing up to 21 recently used application window icons, plus an area for the first 40-50 characters of the titlebar text for the highlighted icon's window. ALT+TAB brings up the dialog with the last-used window's icon highlighted; ALT+SHIFT-TAB brings up the dialog with the tenth-last-windows's icon highlighted. So long as it is up (so long as ALT is held) TAB cycles down the stack, and SHIFT-TAB cycles up the stack, highlighting icons and showing the beginning of the corresponding window's titlebar text. At its heart this facility is an application switcher, which has been pressed into service as a document switcher as well by modern apps that create multiple top-tier application windows for their documents. It is completely OS-defined and -operated, and I have never seen an app steal those keystrokes. (For completeness, Win+TAB is completely a creature of the MS-Windows taskbar, cycling in order of appearance on the taskbar, starting from the beginning of the first row each time - plus you need to press [Enter] to actually switch to that window. That gets old very fast with numerous windows open, and the whole facility is almost useless as a task-swicther compared to ALT+TAB, given that the titlebar text is not shown. It's a shame, a horrible waste of a key-combo. Now you know why I wish keyboards had another modifier key - Microsoft wasted one :-(. ) So, if the 4xp CTRL+TAB+... behaviour is desired, I'd suggest following Matthew's scheme except that SHIFT+CTRL+TAB would be used to switch areas, in one direction only, on all platforms, CTRL+TAB would work as 4xp, except on MacOS, and except in <TEXTAREA>s, where it would insert a tab character. The one glaring disadvantage of this is that SHIFT+CTRL+TAB is a horrendous key-combo for those with accessibility problems, who would otherwise benefit most from a keyboard method of moving from area to area. The alternative would be to let the 4xp CTRL+TAB+... behaviour die a death, and follow Matthew's proposal, letting CTRL+TAB and CTRL+SHIFT-TAB cycle forward and back among areas on all platforms, except in <TEXTAREA>s where CTRL+TAB would insert a tab character, CTRL+SHIFT-TAB would do nothing, and TAB and SHIFT-TAB would move to the next or previous focusable element or area. (This last would provide more consistent navigation). This would be a drastic move, but one that would arguably be more beneficial than keeping CTRL+TAB+... for document window cycling. dean_tessman@hotmail.com, please argue back; not having used that behaviour myself, I'm sure I've missed a subtlety.

I think we all agree that we really need/want to switch between areas. Yes, this is a priority. I tend to want to use Ctrl+Tab for simplicity reasons for this function. I'm still am not sold on the Ctrl+Tab for entering tab space. The Shift+Ctrl+Tab is rough for users with disabilities But because of legacy it may be acceptable solution with a few changes. 1) It would have to include Sidebar (if open) in the cycle and 2) when it cycles back to a multi item area it would have to return to the same point of regard and focus on the same item that last had focus in that area. I know the last violates the Shift for reverse legacy but for usability I think that this would work better. But because I have reservations I can do a little research. I'll survey some people with disabilities to see how they use the keys and some keyboard navigators with out disabilities as well. Can we agree to take this data into consideration? As far as the Entering Tab space goes we already have lots of data there. There are very few web pages with multi line text fields. Since this is the case users will have little familiarity with the "secret code" to get out of the multi line text field. What I mean is that they will be habituated to Tab and will not be able to figure out that Ctrl+Tab works like Tab in only one case. We have seen this already in field observations.

If I understand you, lake, you're advocating that rather than Ctrl+Tab operating in a strict cycle for areas, it operate using the same stack method as Alt+Tab does on Windows. That would seem a good idea, since it would let me switch between two areas repeatedly without using different key combinations (or the same combination a different number of times) for each direction. But if you do that, you really need to implement a popup, like Windows' Alt+Tab window-switcher, to advertise the possibility of switching between areas other than the last two by pressing Ctrl+Tab+Tab (etc). And a similar popup for the MacOS window switcher, too, I guess. No, I don't like the idea of entering tab characters in multi-line text fields either, and since other browsers don't allow it there probably aren't any Web apps which require it. But my proposal was assuming that entering tabs in multi-line text fields had to be accommodated somewhere. The design could be a lot more consistent if that was not the case. Perhaps that bug should be resolved -- either as FIXED or as WONTFIX -- before the spec for this bug is finalized? Since Ctrl+Tab is being seriously considered for a different purpose from that used in 4.x, maybe this bug should not be on the relnote radar?

Surely, if we implement decent configurability in the key binding, all of this arguing is reduced to "what should Mozilla do out of the box"? This means that the "some people like broken functionality" arguments are null and void, because they can "re-break" Mozilla to their taste. Mozilla _will_ have reconfigurable key bindings, won't it? :-) Gerv

Gervase -- yes. Given that Mozilla consists of plain-text XUL, CSS, and JS, and open-source C++, the entire Mozilla user interface design process is little more than an argument about defaults. That doesn't mean it's not a valid argument! I've thought some more about Ctrl+Tab and Ctrl+Shift+Tab working using the same stack method as Alt+Tab and Alt+Shift+Tab, and I've changed my mind. I actually think Ctrl+Tab should do an ordinary cycle between areas, not a stack-switch. Switching between areas is more closely related to switching between individual interface elements (Tab/Shift+Tab), than it is related to switching between windows (Alt+Tab/Shift+Alt+Tab). Therefore, Ctrl+Tab should use ordinary cycling like Tab/Shift+Tab does, and not stack-switching like Alt+Tab/Shift+Alt+Tab does. Otherwise, the user may never realize that Ctrl+Tab lets you get to the sidebar, as well as just the content and the location bar -- whereas with Alt+Tab it's fairly obvious that it can be used for getting to windows other than the topmost two.

Broken link fixed. Apologies for the inconvenience. New version has more detail on the uses of the Tab key.

Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2

*** Bug 35134 has been marked as a duplicate of this bug. ***

The reporter of bug 35134 points out that in NN 4.x on Windows, the [F6] key does the same action as ctrl+tab; I verified this on WinNT with 4.6 and 4.72. [F6] does nothing with NN 4.7 on Linux. Enabling the 4xp functionality for [F6] might make it more palatable to "steal" ctrl-tab from its 4xp functionality on Windows, as discussed here, to implement area switching. And yes, there is no reason for making it work stack-wise -- the whole point is to have quick movement to a small number of areas, so cycling through again after overshooting should not be too annoying.

As it stands, I'm not sure what the action item is for saari here: In other words, this needs a spec on what the meaning of Ctrl-Tab is for the main app windows, and within dialogs. Moving to M18 in the interim.

saari, The link to the spec is here. http://gooey/client/5.0/specs/keyboard/kybdnav2.htm All non Netscape people Contact me for information.

Is this the relevant spec'd behaviour? This will cycle the focus through the general areas in the browser the order will be: 1.URL in Window 1 2.Page in Window 1 3.Sidebar in Window 1 (if open) 4.Window 2 5.Window 3... 6.Window 1 The first operable item will have focus for a new window. For returning to windows the application will return the user to the view and focus they had when this window was last active. The window will be returned to the state it was left in. the Focus and Point of regard or view as it was when the window last had focus. saari -- is this really your bug, or is this an XPApps bug?

For the browser this is the expected behavior. For mail it is slightly different. Folders area in Window 1 (if Open) 2.Threads area in Window 1 3.Message area in Window 1 4.Sidebar 5.Window 2 6.Window 3... 7.Window 1 (the focus will return to where it was before the Ctrl+Tab series began)

Could the spec be put up somewhere in <http://mozilla.org/projects/ui/netscape/>, please? I have to say I don't like the bits of it that have been published in this bug report so far. I fear that by trying to do multiple things with Ctrl+Tab in this way, you will end up doing none of them well -- where `well' means `in a way understandable by humans'. * Will the window-switching feature of Ctrl+Tab work in a strict cycle (like 4.x does), or in stack order (like Alt+Tab on Windows does)? * What if window 1 and window 2 are both three-pane mail windows? Will Ctrl+Tab switch between areas in window 2, too, before switching back to window 1? - If not, why not? - If so, do you think that having {Ctrl+Tab+Tab+Tab+Tab} do one thing (switch from a Messenger window to another window), and having {Ctrl+Tab+Tab, Ctrl+Tab+Tab} do another thing (move back to the original frame in the Messenger window), will be understandable? * If I press {Ctrl+Tab+...} enough times to switch to window 2, and I then press {Ctrl+Shift+Tab}, what happens? Do I go back to window 1, or do I go to the previous frame in window 2? Give reasons for choosing one over the other. * Do you think that having {Ctrl+Tab+Tab+Tab} as a shortcut for switching from a Navigator window (with sidebar open) to another window, and having {Ctrl+Tab+Tab+Tab+Tab} for switching from a Messenger window (with sidebar open) to another window, will be easy enough for people to discover, that the window-switching behavior is worth including at all? * When a user finally works out that {Ctrl+Tab+Tab+Tab} or {Ctrl+Tab+Tab+Tab+Tab} (depending on the component) switches between windows, do you foresee any problems where a user happens to have the sidebar (or the location bar) closed temporarily, and finds that {Ctrl+Tab+Tab} (in a Navigator window) or {Ctrl+Tab+Tab+Tab} (in a Messenger window) takes them to another window instead of what they were expecting? If not, why not? * How will I know if a given dialog (such as the Preferences dialog, for example) supports Ctrl+Tab for switching between areas -- without actually trying {Ctrl+Tab}, uttering a mild obscenity as I get switched to another window (ok, so the dialog *doesn't* support Ctrl+Tab, then!), and then pressing {Shift+Ctrl+Tab+Tab+...} an arbitrary number of times (depending on which component the other window happens to be, and whether the sidebar or location bar happens to be open in that other window) to go back to the dialog?

Wow. That's going to get confusing. I like Sean's suggestion from a while back. Use F6 to switch through all active windows (either in a consistent order or like Alt+Tab - decide that later) and use Ctrl+Tab to cycle through the active areas (frames, sidebar, preview pane, etc) in the active window. Its not completely 4xp, but it makes more sense than where it sounds like we're heading.

mass-moving all '-' bugs to M20

Putting on [dogfood-] radar.

PMFJI. I hadn't noticed that Communicator uses F6 to switch windows. Windows itself uses ALT+F6 to switch between the top window and the application's next highest window. Windows also uses SHIT+ALT+F6 to activate the application's lowest window. None of these keystrokes restores a minimized window.

Matt I agree that this is not the most eligant way of implimenting things and I have been working on a solution. I do have sufficient eveidence that this will work for the keyboarding comunity as I have poled them on the behavior. However It would be more simple and eligant if we could just use Ctrl+Tab only for switching windows as we had in the past. However this depends on the other keyboard navigation keys being implimenteed. With out these we are forced to find other means of navigation. They are not yet implimented but then neither is this. Here are the proposed nav. keys: Ctrl + Shift + F Give focus to the Folder Pane (returning Mail to the state it was last in) Ctrl + Shift + H Give focus to the Thread Pane (returning Mail to the state it was last in) Ctrl + Shift + L Give focus to the URL field Browser Ctrl + Shift + S Give focus to the Sidebar Browser & Mail Mind you there are very few options left as many of the key combinations are already spoken for but I did my best. I am still working on getting a place to hang the specs where every one can access them.

What's Ctrl+Shift+T used for currently?

Ctrl + Shift + T is used for - Get new messages for selected account and all connected accounts in Mail.

Specific problems: * Ctrl+Shift+F shouldn't be used to go to the folder pane in Messenger, because it is 4xp for searching messages. * I think users would expect Ctrl+Shift+H to either open the home page or open the History window (with the other of those two being activated by Ctrl+H). * Ctrl+Shift+L to go to the location bar makes sense, except that it makes the L keybindings the *opposite* of what they are in IE/Mac (which uses Ctrl+L to focus on the location bar, and Ctrl+Shift+L for Open Location). * Ctrl+Shift+S shouldn't be used for going to the sidebar, because if users of Composer (which has a sidebar) are expecting Ctrl+Shift+S to do anything at all, they'll be expecting it to do Save As (as used in ClarisWorks, PageMaker, Freehand, Photoshop, etc). General problems: * You're going to have to dig into the increasingly-empty keyboard shortcut barrel again in order to find shortcuts for navigating to the list pane, the message pane, and the entry pane in Chatzilla. And you'll have to do it again and again if other components which use panes in their UI are added to the default Mozilla distribution (e.g. a calendaring app, or an open-source Internet telephony client, or whatever). * Nobody is going to remember all these shortcuts. Having specific shortcuts for each pane in each component makes no more sense than having one keyboard shortcut for switching to a Word window, another shortcut for switching to a Netscape window, a third to switch to a Notepad window, etc, instead of just Alt+Tab as a general shortcut for switching between windows. * Using Ctrl+Tab to switch between panes meets the criteria for the `4xp' keyword, because it's what IE uses. Of all the potential users of Mozilla, a greater number are using IE right now than are using Netscape. * You've specified no shortcut here for switching between the category pane and the prefs pane in the Preferences dialog, or the various tabs which will eventually be present in the Page Info window, etc. Even if specific shortcuts were introduced for each of these windows, they'd be very difficult to remember because they would each be applicable so infrequently (unlike a shortcut which was universal in all windows, such as Ctrl+Tab). In summary: if using Ctrl+Tab to switch between windows (with all the consequences of that decision) meets your definition of `simple and elegant', then I cringe to imagine what an example of `complex and ugly' would look like.

If you read my message, I did not say it was simple and Elegant. I said it was NOT. I am attempting to make the best of a less than ideal situation. Yes Ctrl+Shift+S in Email was previously used in 4.X For Search. There are some issues that are currently being hammered out with the search in Mail Feature where I may have to take back my words there. But Ctrl+Shift for "I" "D" "E" and "B" are still open. May be "B" for Bar? And that part about Composer users are expecting Ctrl+Shift+S to "Save As" like (as used in ClarisWorks, PageMaker, Freehand, Photoshop), our target users for Composer are our current users of Composer. These people are probably used to what we are currently using Ctrl+A for "AS" That isn't too difficult to adjust to if you are coming from another product. Let me point out also that those other products do not have to integrate with Email and a Browser and Addressbook and Instant Messenger. As for your argument about Ctrl+Shift+H in Email; that is, the user working on Email would expect that this would either open the home page or open the History window is over doing it a little. Most people in Email would not expect a control for Email to activate functionality in the browser. Or is this a new feature I am not aware of. As for Ctrl Shift+L argument, What? Ctrl +L in IE opens the Open Location Dialog. That is what we are doing now. Ctrl+Shift+L does nothing in IE. So we are matching 4.X and IE in the Shift+L area and we add in the Ctrl+Shift+L. (By the way this is one of the most asked for keyboard features) Next let me touch upon the "General Problems" The first is only a fact of any product increasing it's functionality not of my suggestions. All functionality MUST have a keyboard implementation so the keys available will become more rare as things are added. Next there is the "Remember Problem". Yes, it has been long noted that humans are notoriously unskilled at remembering obscure code. This is why those accelerators are represented in the Menu so there will be a visual reminder both to those using a mouse and those who can not use the mouse. Additionally as you may have noticed currently most accelerators choose some letter in common with the Menu item they represent. This aids memory as well. The combination I have suggested tries to take advantage of that and all of these keys are Shifted Keys rather than mixing the "Case". This also should aid in memory. Now before you fire off another Bug reply I did NOT say this was easy to remember. Only that I think that this is reasonable especially for those who must use the Keyboard. Then there is the IE does this so it's OK if we do. Argument. Well we currently don't. We are a different kind of application than IE. Not only in window/child management. Lastly there is the Preferences Dialog. It is a DIALOG not an application. For Your Amusement,

2000-03-22: "I do like the simplicity of the Ctrl+Tab solution [for cycling between content/location bar/sidebar]. And I generally agree that getting sidebar access is of rival importiance to within application window switching." 2000-06-15: "It would be more simple and eligant if we could just use Ctrl+Tab only for switching windows as we had in the past." 2000-06-20: "I did not say it [using Ctrl+Tab to switch between windows] was simple and Elegant. I said it was NOT." I give up, I really do. I could hang around to ask exactly which previous version of Communicator used `Ctrl+Shift+S in Email ... For Search' (rather than using Ctrl+Shift+F), or which version of Communicator has `"Save As" ... currently using Ctrl+A for "AS"' (rather than using Ctrl+A for Select All), or how Mozilla being `a different kind of application than IE' explains the inversely-correlated market share of Communicator and IE over time ... But I suspect that none of the answers to those questions would be very useful for resolving this bug, so Bugzilla is an inappropriate forum for them. The Aphrodite keyboard spec is there (see URL) if anyone wants to implement it. Lake, if you don't have time to put the Netscape spec on mozilla.org, e-mail it to me and I'll put it on the Aphrodite site. Then non-Netscapers will be able to do a side-by-side comparison of the two. [leaving CC list]

Nominating beta3

This is an unimplemented feature, right? ->Future/helpwanted

This is a feature, and should live at the XPApps level, not xptoolkit. Assigning to don

Nav triage team: nsbeta3+; reassigning to law.

What a wonderful bug. and you marked it nsbeta3+? Is this a spec bug or an implementation bug? Bleh. I just want to point out that ctrl-tab in windows has another meaning. And that ctrl-f6 has long existed for mdi window switching. Testcase [netscape communicator4 win32]: Open Navigator, [Mail] Composer, and Address Book. in Mail composer make sure that you can see the addressing area [Show>Addressing Area]. Switch to navigator. press and hold ctrl-tab. Watch as you get stuck in a loop in mail composer. Why does this happen? Because win32 says ctrl-tab *and* ctrl-shift tab do tab switching. Does mozilla have any tabs? Yes. [I know the addressing Area is no longer tabbed but Preferences:Themes has some] Ok so ctrl-tab has a predefined win32 function and nc4 is stuck obeying it. I like the use of ctrl-tab as region switching [limited to the current window]. Next. F6. You're still in composer. Hold F6. You should get stuck in the Address Book. Why? Windows defines F6 as another form of region switching. In this case, pane[l] switching. Oddly, Addressbook doesn't actually support F6, it just breaks it :o. As such, maybe we should use nagme keyboard help [I'll explain this elsewhere] and do the following: [shift]F6: region switching, [shift]ctrl-tab: something. Win32 has many accessibility features. Among them is Stickey keys [press shift five times]. You get a dialog explaining you have just activated the accessibility option. It explains the rules: [StickyKeys] By pressing the SHIFT key five times you have turned on the SitckeyKeys feature. With this feature, you can lock down the CTRL, ALT, or SHIFT keys. This is useful if you are unable to hold down more than one key at a time. Click OK to turn this feature on. If you do not want to use the feature. click Cancel. [ ] Turn off keyboard shortcut for this accessibility feature. <Vertical:Ok|Cancel|Settings> Since we will be moving people to our new world, and the behaviors of nc4 are broken maybe we should pop up a similar dialog [StickeyKeys activation plays a sound too, this is *important* because it alerts the user that a dialog they aren't familiar with has just appeared and requires their attention] Our dialog can explain that [shift]ctrl-tab and [shift]F6 are now being implemented according to the /following/ simple rules. {I'm not writing the rules, this bug is} [x] I understand. <ok> <[help]> --Yes I know, ok is supposed to be the active item, but I think people who ignore sounds or flashes [if you don't have sounds] should be stuck with a help window explaining the gory details of the feature. [This window should either link to the *published* mozilla keyboard navigation spec or be a copy of it.] Hopefully mozilla will have a preference pane for resetting the stored state for toggles like this one. As for switching areas, windows encourages left to right, top to bottom switching. Unless the sidebar is to the right of the content area, it should logically be encountered between the location bar and the content area. At the risk of being shot I'd be tempted to remove nsbeta3+ asking for reconsideration and a clarification of what PDT wants done with this bug. Marking All/All since we've definately morphed this bug. lake. Can we please have access to kybdnav2.htm? Blake, as a mozilla QA I'm asking you to encourage this spec to be published externally. If it is not, please encourage someone to mark this as CANTFIX: NO PUBLIC SPEC PDT this bug is FUTURE, who exactly do you want to solve this bug? I suggest you reconcile that with nsbeta3+

Oh dear. I'm removing nsbeta3+, for obvious reasons (I hope). If it is feasible to whittle this discussion down to a reasonable explanation of what each key should do, and, that some reasonable consensus of the participants in this discussion can agree to that, then please add that reasonable explanation to the bug and mark it nsbeta3+ again. My take is that Alt-Tab is good enough and the rest of the issues (switching to areas within the browser) have their own bugs.

I've got another complaint about this. Here's my proposal: Ctrl-Tab and Ctrl-Shift-Tab cycles between content/location-bar/sidebar (and appropriate mail panels, where applicable). Tab/Shift-Tab cycles through links/controls in content/sidebar/etc. Watch the other bug, too (bug 48251). mpt has bailed on this one; does anybody else have comments? Be warned: It's this or nothing, probably.

Wow, this has gotten out of hand, I agree. I like your idea - keep it simple for now. No sticky keys, no nothing. And it seems to me that this is very similar to, if not exactly the same as, how IE handles it. But we need to get some sort of keyboard navigation in, that's for sure.

I'll atach a new version of the Seamonkey spec with out the gifs if any one wants to bang on it. The big problems are how to switch between windows with in the application and enter tab space in a form field. Please don't suggest Tab to enter tab, and Ctrl tab to get out of th field. the spec explains why this is not suggested.

Updating summary to match suggested solution, and, marking [nsbeta3+] (again).

I've perused the spec and it scares me.

Which parts scare you? <ontopic> The controls for navigating between frames seem consistent with what you've proposed here, Bill, so it sounds like that should be a go. Use Ctrl+Tab and Ctrl+Shift+Tab to cycle between frames and leave Alt+Tab for switching between windows (or whatever is the standard for the OS). 4.x desperately needed a faster way to switch between frames. </ontopic> <offtopic> General comments on the spec... Neither of the last two ideas in General Browser Naviagation make much sense to me. - Ctrl+Enter is a very scary shortcut, especially since it is also a shortcut to send mail. This will be very confusing. - For the tooltip, it should behave exactly as if I moused-over the item. Display after 1/2 a second (or whatever) and stay visible for two seconds. No pressing of ? or whatever it says. Trigger or Activate an Item - I don't like the part about Space Bar activating a link. In 4.x, the space bar scrolled by one full page. This was great when reading long documents. Enter should always activate a link if one is active. If I'm in a form field, it should trigger the Submit action. Form Controls only - Home key to move to row 1 column 1 of a multi-line edit control is definitely not a Windows standard. How am I supposed to get to the start or end of the current line? - Ditto for end Viewing More of a Page - Ctrl+Left Arrow/Right Arrow to scroll one full screen left/right ... "This behavior is consistent with previously implemented behavior." I've never seen this in 4.x or any other Windows product. Sidebar - I don't know why there needs to be a different shortcut to open and to jump to it. I prefer Ctrl+Shift+B, as Ctrl+Shift+S, to me, is a shortcut for Save All. </offtopic>

Nothing specific, really. Mostly the fact that each and every reader will likely have their own page of questions/comments like yours. I noticed that you yourself identified at least one proposal as a "very scary shortcut."

This spec isn't written in stone so Email me with <OffTopic> stuff and we can see what should be done. As an aside the Ctrl+Shift+S was an editing error It should have read Ctrl+Shift+B There is a specific reason why the delay and display of keyboard activated tooltips is longer I'll add this to the spec. And the space bar should not activate a link just the controls like radiobuttons and such. Just like you mentioned. Since this is all off topic I'll stop here and ask people to comment to me for clarification and changes.

PDT downloading to [nsbeta3-] radar.

[Sanity has been restored, so returning to CC. I've mailed Lake with suggested corrections to her keyboard navigation spec. E-mail me if you want a copy.]

This bug is way out of control. Suggest closing, and opening a summary bug. This is just depressing to read a bug this long, I stopped caring before I even got halfway through this.

Please keep the Ctrl-TAB functionality as in current Navigator 4.x. This is the best key combination for cycling between open web pages. Try to open 10 web pages and cycle with Alt-TAB - it's insane !!. That's one of the reasons why I hate IE - among the others ;). And besides Opera uses Ctrl-Tab for cycling too. Missing the Ctrl-Tab function is the only reason for NOT using Mozilla as my primary browser - I still use Navigator because of this. I think Ctrl-Shift-Tab should be used to cycle back - this is the most common use than cycling thru the page elements.

I'd like to see both Ctrl+Tab and F6 be used for switching between panes.

(Shift)+Ctrl+tab and (Shift)+F6 need to cycle through the set of all panes and frames, same as IE. Sound good? Therefore, this is a dup of 24423 *** This bug has been marked as a duplicate of 24423 ***

Verified dup.

I still cannot switch between tabs in 2002010208. Ctrl+Tab brings keyboard focus onto the correct tab, but doesn't make it visible. Open multiple tabs. Make sure the first has some links on it. Keep the second tab visible Press Ctrl+Tab till you get to the URL Bar, then Ctrl+Tab again. Now press tab and look at the status bar. You'll notice the links on the first tab become active. Press Enter on any one, and it loads in that tab. All this while, the second tab is still visible.

ctrl-pgup/ctrl-pgdown should switch tabs...