Firefox:Configurable Keybindings

Introduction

Firefox extensions and other functions can fight for keybindings. We should offer the ability for users to configure their keybindings and choose from predefined schemes.

Implementation

The set of <command>s in the browser.xul file is the set of commands for that window. Each command should be modified to include the name of the command by slurping in the text from the appropriate menu item. This would show up in the UI (See "Editor" below).

<key> elements observe <commands> so the connection between the two would be handled by the Editor. Extensions and browser commands insert items into these sets and the Editor would read from them.

The challenge is to create something that works well and yet does not have an effect on Ts/Txul. One implementation strategy might be to use the default hardcoded set until after the window is shown, then in delayedStartup() or something similar load the definition file and create the real keybindings. The downside would be that there would be a brief (probably unexploitable) period in which the browser window was showing with the incorrect "default" keybindings.

Editor

UI TBD. Some kind of list showing a configurations menulist (with various defaults + user ability to save theirs). File should be saved in profile so it can follow them around.

Defaults should include:

• Firefox
• IE
• Netscape 4
• Safari

etc

The editor and most of the logic excluding the default sets should be generic such that they will work for Thunderbird and other applications.

Distribution Options

• on by default, available through a menu item
• off by default, shipped as an extension
• not shipped, available as an extension through update.mozilla.org

Questions that affect this are related to how much this is something for users of extensions, advanced users and the like. The answer is that this is probably a power user feature and as such should be an extension. The hesitation I have when I make this claim is that it is a function that relates to manipulation of other extensions and so could be considered part of the "base".

Regardless, source would be hosted in cvs.mozilla.org and this would be a "supported extension" in that we'd commit to upgrading it with every release.

Work Estimate

2 Weeks

Questions and Suggestions

Should this extend to binding keys to fields on Web pages? For example, letting users bind a key to the "Additional Comments" field on Bugzilla? That might address the problems we have with accesskey="" being a pain.

Comments Callek

I would personally say distribute by default, on by default, removeable via advanced options, most people would love its use, (I assume), and have a need for it, though would have no clue to look at UMO to use it, and with the proposal here should be simple enough for your average user to use without ruining much of their set-up at all...so on by default, removeable in the same vein that DOMi is addable. Justin Wood (Callek) 02:35, 3 Jan 2005 (PST)

Comments Waldo

Please remember that the keybindings that are set need to be shown correctly in Help documentation! If the user can edit everything willy-nilly, having a static Help document that only reflects the shipping keyboard shortcuts is going to be very nearly useless. --Waldo 02:32, 13 Jan 2005 (PST)

Comments Joe Walp

Implementing this reliably is nontrivial because keybinding is controlled via:

• OS bindings
• event handlers attached to the wrapped DOMWindow object by the loaded page w/ capture
• event handlers attached to parents of the focused HTML element on the loaded page
• handler entities defined via XBL
• event handlers attached via XBL [rare]
• event handlers attached to the window object w/ capture
• event handlers attached to parents of the focused XUL element
• XUL key entities

In some cases it's not obvious what precedence these bindings should have. And I expect that some application-level behavior that ought to be configurable is currently implemented as XBL handler entities. Changing this could be tricky.

Managing key entities is complicated by a bug. If you remove a key entity then invoke the previously bound action, it causes a crash (ref: Firefox 1.5).

For the StumbleUpon extension, I opted to use event handlers attached to the window object w/ capture. Feel free to contact me if you're interested in the justification for that.

-- Joe Walp 05:01, 24 September 2006 (PDT)

Comments Christopher Friedt

I think that configureable keybindings are definitely a good idea. However, I lack the in-depth experience of hacking Mozilla/Firefox.

Joe is very correct though. If this is implemented, it would need to consult the windowing system (Gnome/KDE/Windows, whatever) to see if there are any collisions. Each windowing system also has their own policies. For example, some do not even acknowledge collisions, but retain a queue of callbacks per keystroke, so that one keystroke could lead to several actions taken.

The one idea that I thought I could contribute, would be to have a simple interface to the keystroke preferences a la about:config, where users could simply type in an action/keystroke combination:

action	keystroke
closeOtherTabs	Ctrl+Shift+w

maybe about:keystrokes ?

Ideally, one would be able to go into Preferences, and edit this list interactively. That would obviously eliminate much of the errors that could be had if the keystroke preferences were edited manually (like if the key didn't exist in the windowing system, or if it was already in use).

In the hypothetical preferences section, each action would be listed. For each action, the user could click on the 'keystroke' entry to enter a new keystroke, hit BackSpace for default, or Esc to cancel. If the the keystroke was already in use by mozilla or the windowing system, then the previous keystroke would be returned and the user would be notified via a message box.
-- Christopher Friedt 10:45, 14 September 2007 (CET)