30864 - Feature: Ctrl+Tab to quick-switch between "panes"

Status: VERIFIED DUPLICATE of bug 24423

(Core :: DOM: UI Events & Focus Handling, defect, P4)

Description

[:deanis74]

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

Comment 1

[Gervase Markham [:gerv]]

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 ***

Comment 2

[:deanis74]

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.

Comment 3

[Gervase Markham [:gerv]]

<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

Comment 4

[Asa Dotzler [:asa]]

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.  

Comment 5

[Peter Trudelle]

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

Comment 6

[Dan M]

More of a key binding, event thing. Chris?

Comment 7

[leger]

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

Comment 8

[Sean Richardson]

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 [e-mail]

In bug 19446, [e-mail] 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 [e-mail] and [e-mail] 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.

Comment 9

[Lakespur Roca]

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.

Comment 10

[Matthew T (active 1999-2002)]

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).

Comment 11

[Sean Richardson]

[e-mail]: 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.

Comment 12

[Matthew T (active 1999-2002)]

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.

Comment 13

[Matthew T (active 1999-2002)]

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

Comment 14

[:deanis74]

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?

Comment 15

[Lakespur Roca]

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.

Comment 16

[:deanis74]

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

Comment 17

[Matthew T (active 1999-2002)]

> 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.

Comment 18

[Sean Richardson]

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. 

[e-mail], please argue back; not having used that behaviour
myself, I'm sure I've missed a subtlety.

Comment 19

[Lakespur Roca]

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.

Comment 20

[Matthew T (active 1999-2002)]

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?

Comment 21

[Gervase Markham [:gerv]]

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

Comment 22

[Matthew T (active 1999-2002)]

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.

Comment 23

[Matthew T (active 1999-2002)]

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

Comment 24

[Peter Trudelle]

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

Comment 25

[Sean Richardson]

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

Comment 26

[Sean Richardson]

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.

Comment 27

[Peter Trudelle]

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.

Comment 28

[Lakespur Roca]

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.

Comment 29

[John Morrison]

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?

Comment 30

[Lakespur Roca]

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)

Comment 31

[Matthew T (active 1999-2002)]

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?

Comment 32

[:deanis74]

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.

Comment 33

[Peter Trudelle]

mass-moving all '-' bugs to M20

Comment 34

[leger]

Putting on [dogfood-] radar.

Comment 35

[[e-mail]]

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.

Comment 36

[Lakespur Roca]

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.
   

Comment 37

[:deanis74]

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

Comment 38

[Lakespur Roca]

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

Comment 39

[Matthew T (active 1999-2002)]

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.

Comment 40

[Lakespur Roca]

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, 

Comment 41

[Matthew T (active 1999-2002)]

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]

Comment 42

[Lakespur Roca]

Nominating beta3 

Comment 43

[Peter Trudelle]

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

Comment 44

[saari (gone)]

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

Assigning to don

Comment 45

[verah (gone)]

Nav triage team: nsbeta3+; reassigning to law.

Comment 46

[timeless]

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+

Comment 47

[Bill Law]

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.

Comment 48

[Bill Law]

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.

Comment 49

[:deanis74]

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.

Comment 50

[Lakespur Roca]

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.

Comment 51

[Lakespur Roca]

Attachment: Seamonkey keyboard navigation spec.

Comment 52

[Bill Law]

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

Comment 53

[Bill Law]

I've perused the spec and it scares me.

Comment 54

[:deanis74]

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>

Comment 55

[Bill Law]

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

Comment 56

[Lakespur Roca]

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.

Comment 57

[leger]

PDT downloading to [nsbeta3-] radar.

Comment 58

[Matthew T (active 1999-2002)]

[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.]

Comment 59

[Chris McAfee]

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.

Comment 60

[rexxx3000]

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.

Comment 61

[Jesse Ruderman]

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

Comment 62

[Aaron Leventhal]

(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 ***

Comment 63

[James Green]

Verified dup.

Comment 64

[Philip Tellis]

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.

Comment 65

[Boris Zbarsky [:bzbarsky]]

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