This FAQ and cross reference will help us find unused keystrokes, look for patterns, see what has or hasn't been implemented and have consistency in our UI. We want implementers to follow this spec, so if you wish for something other than what's here, please let us know where the spec falls short. Before suggesting changes, make sure to read this entire FAQ, as it spells out our current policies and our reasons for them.
We realize it's a good idea to leave as many keystrokes open as possible, for future expandability. If you see keystroke commands in the spec that are superfluous, let us know so we can clear more space. Some hotkeys may end up being relegated to a special configuration file or preference, for the particular set of users that need them.
- Cross Reference
- Four Major Platforms
- Modifier Key Policies
- Tab Behavior
- Avoiding Function Keys for Crucial Roles
- Potentially Destructive Keys
- Macintosh Keyboard Differences
- Accesskey Conflicts
- Keyboard Configurability
- Summary for Coders
- Informational Links
- Keyboard UI Mailing List
Here's an outline of all the global hot keys in Mozilla, for the browser, editor, mail-news and widgets. This document does not discuss underlined menu accelerators and the like, as those are part of i18n.
Please read the entire FAQ before recommending changes
- Key binding: a piece of data that defines the connect between a keystroke and a command.
- Modifier: a key that is used in combination with another, such as Alt, Ctrl, Shift or Cmd (a.k.a. the Apple key).
- Hotkey: a key with a binding that crosses widget boundaries, and can act globally in the current window.
- Accelerator: a key who's behavior is defined locally by the widget the focus is currently in.
- Accel key: the modifier used in conjunction with letter and number keys on a given platform for hotkey commands.
- Shortcut: ambiguous term, could mean any kind of keystroke command. Not used in the spec.
- Accesskey: an attribute in HTML or XUL for defining an accelator. A letter in the command name that corresponds to the accesskey is usually underline.
We define the keyboard combinations for 4 major platform groups. Our spec currently only deals with the first three - it doesn't talk about OS/2. At some point, we may fold in the OS/2 keyboard information.
- Windows (includes BeOS)
- UNIX (includes Linux)
- Mac OS
- OS/2 (these keybindings are set by IBM)
What's the modifier key situation? When is Ctrl/Shift/Alt/Cmd used?
One "Accel" Key per Platform
For hotkeys, we normally use only one accelerator key per letter. On Mac we default to Cmd and on everything else we default to Ctrl. The accel letter combination can also be used with shift for a related command. When defining keystrokes in XBL, modifier="accel" is mapped to the appropriate key for that platform.
There are several reasons for this limitation of 1 accel key. First, Mac OS only offers the Cmd key for acceleration, since Alt+Letter combinations are reserved for entering special characters in text. Mac OS applications are not supposed to use the Ctrl key modifier for commands, and Mac users do a double-take when they are told to use such a key combo.
UNIX systems provide a special challenge: the need to support legacy Emacs keybindings that may conflict with Mozilla keybindings. For example, in Emacs Ctrl+A moves the caret to the beginning of a line, but in Mozilla, Accel+A is the select all command. Which should win out? In 4.7, we worked around this by having Alt as the default accelator key. However, this goes against the expectations of many newer users, as well as the default behavior of the Gnome and KDE environments. If we consider a secondary accel key key for Unix systems, we have to consider it is possibly already taken up by an Emacs key binding.
A final issue is that HTML defines the accesskey attribute, which allows page authors to define accelerators for webpages, usually indicated with underlined letters. Where possible, a modifier key should be reserved for accesskeys.
Therefore, while it may be desirable to use Alt as a secondary accel key on the Windows platform, this would leave it as the sole beneficiary of those bindings, and we would still need to find another key combination for the other two platforms. So far, it's been simpler to try finding consistent key combinations that work for all platforms at once. This means that for hotkeys, we can only assume one modifier key per letter, with and without shift.
No Ctrl key combos on Mac OS
The Mac human interface guidelines ask developers to use Cmd, not Ctrl. Using Ctrl for hotkeys would confused many Mac users. We can, however, offer Ctrl combinations for user-defined keystrokes (once we start offering keyboard configurability).
Use "Accel" key with letter and number keys, specify exact modifier for other keys
In our spec, the Accel key is the key that can change between Ctrl, Alt or Cmd, thus changing what modifier is used with different letters. For all other keys (numbers, function keys, navigation keys and editing keys like Delete and backspace), our spec says exactly what modifier is used in each command combination. For example, Alt+Left always means "Go to previous page in history". For Ctrl+ combos, we general say Ctrl/Cmd(Mac), to show that Ctrl is used on Windows and UNIX for this command, and Cmd is used on the Mac.
No Ctrl+Alt combinations
On international keyboards Ctrl+Alt is used to access accents and other special characters. Even UK keyboards have 6 Ctrl+Alt keystrokes (11 if you count upper case): á, é, í, ó, ú (acute accentuated vowels) and EUR (Euro currency symbol Ctrl+Alt+4).
In addition, Ctrl+Alt+Letter combos are traditionally reserved on Windows for defining user application startup hotkeys. This isn't set in stone, so if we really start running out of keys, perhaps we can change this policy. For now, consistency is a good thing, and we don't need them.
Try to group related functions together on the same key
For example, we try to reserve Accel+Shift+Letter for commands that are related to Accel+Letter, where possible. This makes our interface more elegant, and makes the hotkeys easier to remember.
Many keyboards from around the world don't support the punctuation you might expect (some don't even have semicolon!). You also can't assume that two punctuation characters are on two different keys. For example, comma may be on a different key from period, or may be on the same key. Also, a punctuation key may be shifted on some keyboards and unshifted on others, and a binding which specifies an unshifted key won't work if shift is pressed (and vice versa). So, while some of our hotkeys can be reassigned by the i18n team, it's a good idea to use punctuation combos for non-essential things, so that we don't lose much if the key isn't available. Here's a set of international keyboard layout diagrams.
Emacs editor bindings always go on Ctrl
Emacs bindings are currently available only on the UNIX platform. On some letters, there is an accel binding, and a ctrl(unix) binding. When these two bindings conflict (as in Ctrl-A or Ctrl-H), the emacs binding wins. Most of the time, the bindings will follow focus, so e.g. if the focus is in an editing field, the editing binding will be used, if the focus is in the browser content area, the browser binding will be used. More information on this in the open issue below.
Open Issue: The default UNIX accel key is Ctrl
The default accel key was Alt in Netscape 4.7. A good reason for keeping Ctrl is to be consistent with Gnome and KDE. A good reason for making it Alt, is that more of the Emacs key bindings are then available for use. Reasonable people disagree on this issue. To learn how to switch your accel key, see the customizing document. It may be desirable to build a pre-made keyboard configuration file for users who want pure-Emacs style control. Akkana Peck has reopened this issue. If you feel strongly either way, please email email@example.com with your preference.
Not all Macintosh keyboards are the same. For example, older macs may not have any function keys at all, newer Macs have F1-F12, very few have F13-F15 (F13-F15 are usually labelled Print Screen, Break etc on PCs). When function keys are present, Mac OS allow users to define their actions (macros). For these reasons we want to avoid the only key binding for a feature being on a function key. If the feature is important or common, it must have an alternative means of activation.
Some Macs are missing keys like "insert" or "end" or "pageup" or "del". The Backspace key is labelled "delete" and represented in menus by an icon, "enter" is a key on the numeric keypad and the key PC users call "enter" is labelled "return". Some have separate "help" keys while others have "help" on the "insert" key. Some have a "clear" key. The layout of keys like Insert, Delete, Home, End, etc. may be different from keyboard to keyboard. That's just the US English keyboards: in other words, the fewer assumptions you make, the happier the users will be.
Mac OS does not have a built in way of walking through the menubar with the keyboard. Mac OS reserves Alt (Option), and Alt+Shift letter combinations for inserting special characters and those required by non-English languages.
Open Issue: Should keys that OS X has taken over be replaced?
As of OS X, Cmd+M and Cmd+H are taken over by the system for the "mimimize windows" and "hide window" commands. Mozilla and Netscape 4.7 used these for "new mail" and "history". We've even heard that Cmd+M now crashes Mozilla under Mac OS X. Are these commands now and forever relegated to using the mouse with pull down menus on Mac? Should we invent new keys for those commands in OS X? Should we make an exception in this case and use Ctrl? We need an avid Mac user who loves keyboard commands to step forward on issues like this.
Another important fact is that we're already going against platform UI guidelines with our Accel+N behavior. The standard on Windows and Mac OS is for Accel+N to open a new document or window of the appropriate kind, depending on the application. For example, Accel+N should open a new browser window in Navigator, a new empty document in Composer, a new message composition in Mailnews and a new card in the address book. Users would use the Accel+digit hotkeys if they wanted a keyboard command to jump straight to a different application.
- The argument against change, is that we'll be changing what people are already used to. Perhaps we should have done it this way from the start, but what happens if we change these common things right under our users' feet?
- The argument for change, is that it's better to do the right thing now, than to assign some strange keystroke for new message compose for Mac users, onlu to possibly change it later. We should follow platform standards, and get rid of our strange use of Accel+N.
Currently, Tab navigates through all links and form elements in a page
Avoid using function keys for important functionality, or provide other equivalents on Mac OS. This is because the Macintosh generally reserves function keys for user defined actions. Some Mac keyboards have no function keys at all.
Certain keystroke combinations are reportedly often hit by mistake by users intending to type something else. Those keys should only invoke undoable or non-destructive actions
Here's our current list of easy-to-mistype keystrokes:
- Modified Enter
- Modified Space
Keys that are easily hit by accident should not invoke an immediate, undoable, destructive action. For example, if Ctrl+Enter was used for immediate mail send, someone might send a rude email before having the chance to edit it. To get around this, we will have Ctrl+Enter bring up a dialog "Send mail now?" with a checkbox that lets the user avoid the extra question in the future.
Web pages can use the accesskey attribute to define keyboard accelerators for their page. For example, on www.microsoft.com/enable, pressing Alt+S initiates a site search. However, Alt+S is also supposed to pull down the Search menu in Mozilla's menu bar.
At this point in time, our solution will be the same as Internet Explorer's. If there is a conflict, the web page's accesskey will get the key. If a user specifically wants to go to the main menu, they will type the menu access key first (normally Alt by itself), then the letter corresponding to the accesskey (such as S for search).
Right now we have disabled Alt as the menu access key in UNIX, because Alt+click can have meaning. To get around this, we need to fix the Alt menu access code to check for a click.
It is now possible to build your own keyboard configuration. We still need to fix some places where Mozilla hard codes specific keys, for example the TAB key is hard coded for link and form navigation in nsEventStateManager.cpp. There are a number of other keys that are defined in the chrome, but are packed away in .jar files. We don't have a solution for changing those easily yet, either.
At some point, we may get someone to build a keyboard configuration front-end. For now, our solution is to have the user edit text files. We can also provide some pre-build keyboard configuration files (any volunteers?). For example, someone may provide bindings for Emacs, Opera or Lynx users. Opera and Lynx have quite a few single keystroke commands in the browser. Single key bindings are great for users that have a great deal of difficulty typing. It also necessitates the use of a "leave form controls" key.
See the customizing document to learn how to use keyboard configurability.
For key combos using letter and number keys, the main cross reference table often lists accel as a modifier. If you use "accel" in XBL Mozilla will automatically choose the right key for you, even if the user changes it in their preferences. For other keys, (function keys, punctuation, etc.) we explicitly say "Ctrl(Win+Unix) or Cmd(Mac)" to indicate this will always be the key used, even if "accel" is otherwise redefined by the user. Even in this case, we still prefer "Command" over "Control" on the Mac because "Control" is used for context menus and very few end user programs use it as a modifier key.
Modifier Keys Demystified
|accel||Ctrl||Ctrl or Alt||Command|
Keyboard Coding Rules
- Never hardcode keynames. Use string bundles. This is also essential for localization, so there is no excuse.
- Avoid making important features available only on non-alphanumeric keys (punctuation, numbers and function keys), these might not be present or easy to type on Mac or non-US keyboards.
- For combos using letter or number keys, use "accel" or "shift,accel" in XBL.
- For other key combos be explicit: use "ctrl", "alt" and "shift" on Windows and Unix; use "meta", "alt" and "shift" in the Mac keybindings file.
Key Bindings Files
Content area bindings
- htmlBindings.xml - general key bindings for content area
- mac/platformHTMLBindings.xml - Mac OS platform specific bindings
- os2/platformHTMLBindings.xml - OS/2 platform specific bindings
- unix/platformHTMLBindings.xml - UNIX platform specific bindings
- win/platformHTMLBindings.xml - Windows platform specific bindings
- viewZoomOverlay.dtd - for zooming and shrinking text (Ctrl+- and Ctrl+= right now)
- messenger.dtd - this is where the mail commands are set.
- mailTasksOverlay.dtd - where Ctrl+2 is set as the command to bring up Mail-news
- treeBindings.xml - for tree widget
- tabBindings.xml - for tab widget
- radioBindings.xml - for radio buttons
- xulBindings.xml - for simple widgets such as checkboxes, etc.
- Keyboard navigation info for the Opera browser:
- Microsoft keyboard UI for all Microsoft products, and Windows in general
- Master list of International keyboard layout diagrams. This is a great way to see the huge differences i18n has to deal with. You can't take too many keys for granted.
- List of keyboard bugs in Bugzilla
- The customizing document - explains how to change Mozilla's key bindings globally or in your profile.
Please discuss general keyboard issues on the Mozilla-Accessibility mailing list. We really want people to follow the keyboard plan, so if you see Bugzilla bugs that differ from the plan, please point it out on the bug and in the mailing list.