front end for customizing keyboard shortcuts (configurable/user-defined keys)




19 years ago
a month ago


(Reporter: mikko.rantalainen, Unassigned)


(Depends on: 5 bugs, Blocks: 4 bugs, {embed, helpwanted, topembed-})

embed, helpwanted, topembed-
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [feature] [T2] Read Comment 82 before contributing)


(3 attachments)



19 years ago
Everybody seems to agree that shortcuts (and keyboard accelerators) are the 
right thing. However, everybody seems to disagree which key to use for specific 
action. What I'm suggesting (if possible) is to allow user to remap at least 
all shortcut keys and even accelerators. For example I'm used to ALT-D to 
change focus to address bar (equal to win32/IE5 key mapping) and I would want 
to use it with mozilla also (in both windows and linux!).
do you mean a way of changing the accelerator key (ie, switching from using Ctrl
to Alt, or vice versa)? or, changing the keybinding itself?

if the former, there's a way to do this already in your prefs.js file.

if the latter, you're requesting a frontend/UI for such a feature?
Severity: normal → enhancement
Hardware: Other → All

Comment 2

19 years ago
I'm requesting frontend for keybinding. It's much easier to see a possible 
action and select keybinding by simply pressing keys you want to use. This 
should also check for conflicts between different bindings. If there is no 
(easy enough) way to do frontend I think including file listing of all possible 
actions and simple 'how to bind keys your own keys' would be enough. Changing 
the accelerator key should be in frontend in any case because at least in linux 
some users are used to meta/alt-shortcuts whereas others are used to ctrl-
shortcuts. Under windows there is no reason to change accelerator key because 
all apps use ctrl anyway.

I'm assuming that internally all actions are indentified by strings and a 
binding is of style "bind alt+ctrl+v file-view-source". I have no idea how key 
bindings are done in real life in Mozilla.

It may sound like a much of work but if mozilla toolkit is to be used in 
another projects I think this is needed.
thanks! confirming enhancment request. cc'ing a buncha folx who might take a
shine to this. ;)

don/anyone, who should own this puppy?
Ever confirmed: true
Keywords: helpwanted

Comment 4

19 years ago
Adding hyatt to the cc list too.
I'd love to take a stab at this, if we could convince powers-that-be that it's
worth spending time on.  (Tell 'em Microsoft does it, e.g. in VC++ ... that'll
make them take it more seriously.)

In the meantime, Mira, take a look at
There are some notes on how to change your keybindings.  Unfortunately in the
current release it requires unzipping the jars, modifying the bindings there and
zipping them up again, but it's supposed to get easier in future releases.
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment.
Assignee: don → vishy

Comment 6

18 years ago
over to akkana, nsbeta1 license-to-kill
Assignee: vishy → akkana
Keywords: nsbeta1

Comment 7

18 years ago
I just sent 18508, on the backend which would be needed before a front end would
be possible, over to hyatt.  I'll keep this one to cover possible front-end work
and add a dependency.

I'll leave the nsbeta1 keyword in place, but unless 18508 gets fixed, this one
will be impossible.
Depends on: 18508
Summary: feature request: option to remap keyboard shortcuts → feature request: front end for remapping keyboard shortcuts
Target Milestone: --- → Future

Comment 8

18 years ago
minus.  THanks for following up on 18508.

Keywords: nsbeta1 → nsbeta1-

Comment 9

18 years ago
I just checked in a fix for 18508, and updated the customizing document to
explain how to set user key bindings for text controls, editor and browser
windows.  (Nobody will admit to knowing how mail/news key bindings work, so they
remain a mystery, alas.)

That means that all we need now is a little program that can create and modify
the XBL key binding format, and a way of giving that program a list of the
available commands.

Comment 10

18 years ago
Un-futuring since the back-end is now in place.
Summary: feature request: front end for remapping keyboard shortcuts → feature request: front end for remapping keyboard shortcuts (user-defined keys)
Target Milestone: Future → ---

Comment 11

18 years ago
Re-futuring.  This isn't something that's on aol's or my manager's agenda (in
fact, it has nothing to do with my job here).  That's why it's helpwanted.  I
took it because I think it would be a nifty hack that I'd love to help with if I
have some free time, which I don't at the moment.  If anyone wants to see it
done soon, they should pitch in and write something.  Besides, I'm practically
XUL-illiterate, so it would be much more efficient if this were done by someone
who's already good with XUL (or wants to become so).
Target Milestone: --- → Future


18 years ago
Blocks: 47199
akkana: I could do with some thoughts on how this might work. It seems to me 
(according to the customising doc) that we have to gather bindings from multiple 
Various .xul files all over the place.

How would we store user bindings? Would we overwrite the original ones in the 
files named above, or would we need some sort of overlay mechanism? Is there 
some way of changing them in-memory? (There should be.)

How hard is this?


Comment 13

18 years ago
No matter what solution is selected, the UI should always show the user what the
*default setting* was - and have a button to reset all to defaults values.

I'll file a bug for this for ALL prefs (done: bug 76648).
*** Bug 77816 has been marked as a duplicate of this bug. ***


18 years ago
Summary: feature request: front end for remapping keyboard shortcuts (user-defined keys) → front end for remapping keyboard shortcuts (user-defined keys)
Whiteboard: [feature]

Comment 15

18 years ago
Created attachment 43971 [details]
screenshot of perfect frontend, from Textpad
*** Bug 93862 has been marked as a duplicate of this bug. ***

Comment 17

18 years ago
Mike T: There's no such thing as perfect frontend. If you simply want to rebind 
menu item accelerators I'd prefer more the way GIMP does it. Simply point menu 
item and press key combination you would want to use for it. The same works for 
any GTK application under X11, but not all applications can save those changes.

Also, I think that TextPad frontend should use a tree view on the left and only 
one listbox. The Categories listbox changes the contents of Commands listbox 
(simply a guess). Selecting an item in a listbox shouldn't change anything 
else. By the definition of listbox, it's for selecting items, not for doing 
actions. This is the same thing as some some web sites using radio buttons or 
comboboxes with javascript for navigation - one shouldn't do it.

Comment 18

18 years ago
Mira: The GIMP method sounds intriguing, but how will users know how to do it?  
Wouldn't it be logical to put keyboard assignments in Edit > Prefs?

Listboxes: whether the UI uses one or two doesn't matter as long as people find 
it easy to use.  Textpad uses almost the same interface as Word for remapping 
keys.  This is a familiar interface.

If you're really set on using one listbox, Mira, you may like the Homesite 
screenshot below.

Comment 19

18 years ago
Created attachment 45530 [details]
screenshot of alternative UI
*** Bug 95533 has been marked as a duplicate of this bug. ***
It should allow binding several (two, at least) combinations for each action.
That way more than one people can use one Mozilla and default combinations can
still be used.

When defining a key already in use, it should ask user: "Ctrl-T is already
assigned to 'Open new tab'. Would you like to replace it? [YES] [NO]".

*** Bug 110521 has been marked as a duplicate of this bug. ***
Thought I'd throw in my 2 cents': I'd like to see a simple page or box listing
the current bindings with buttons for <New Binding>, <Delete Binding>, <Change
Binding>.  For <New Binding>, dialog for <Press Mozilla key combination> then
check validity then <Press New key combination> then check for conflict then add
to list.

An efficient way of coding the bindings I think may be some form of jump table,
which is probably used in EMACS.

Comment 24

17 years ago
*** Bug 108636 has been marked as a duplicate of this bug. ***
Blocks: 36922
Blocks: 69981
Blocks: 108816

Comment 25

17 years ago
The first step here seems to me to be getting the list of available commands, as
Gerv mentioned before.  Is there a way to iterate through all of the
keybindings, breaking them into browser, editor, etc. like they are separated in
the bindings files?

Comment 26

17 years ago
I don't know of an easy way ...  but the bindings are per-widget, so bindings
for the browser window are separate from editor window bindings are separate
from text field bindings, etc.  So it's got to be possible.
I think this bug is invalid, because it would not be an enhancement. The 
ability to customize keyboard shortcuts is ridiculously complicated for 
something as simple as a Web browser should be. If particular keyboard 
shortcuts in Mozilla are unnecessarily difficult to use (such as accel+L 
instead of access+D), file individual bugs for them.

Comment 28

17 years ago
Perhaps this wouldn't be an enhancement from a usability point of view, as you
suggest mpt.  On the other hand, I don't think this should be invalid.

Filing bugs on individual issues probably isn't the solution since there are
already cases where legitimate usability concerns go against the desires of a
significant number of more advanced users (for example the bug on using PgUp and
PgDown to switch between tabs).  

I don't think my preferences should trump the carefully considered decisions by
the UI people in the community.  It would still be nice to choose my own way for
some things, and remapping keyboard shortcuts would be very nice for that purpose.

It seems this case is similar to bug 41888 because it may impact usability
therefore doesn't need to be visible to the average user or even turned on by
default.  I personally don't care if this is buried deeply, as long as it's there.

It's not something I personally want urgently, but I reiterate that I don't
think this is invalid.

Comment 29

17 years ago
I'd like to express agreement with Christopher.  Although I'm
not a Mozilla developer -- so I won't debate how hard this would
be to implement -- as a user I consider the ability to re-map keys
to my taste critical to true ease of use.  A browser may be "simple,"
but it is used all the time, so customization matters a lot.  
If I were to name the one apsect of Mozilla (and other browsers)
that slows down my browsing most, this might be it.

Though it could be a long-term job, making as many actions as
possible (re-)mappable would, I think, be appreciated by many
technically proficient users.  Casual users would, of course,
never have to alter the (judiciously chosen) defaults.
I don't think remapping keystrokes needs to be that complicated.  A "recorder"
key that gets the current keystroke and gets the new keystroke.  I think it will
be necessary to be able to open a window of remapped key assignments.

I suppose this could all be done in a pref (except the window), and the first
example remap in the Help would be to remap that pref to a keystroke, ha ha.

Comment 31

17 years ago
I'd like to second Christopher and Levy. IMO a good program should offer as much
control to the user as possible. Therefore shortcuts remapping while not being
fundamental would be very nice.

Comment 32

17 years ago
I agree with mpt that this should be wontfixed.  Fixing this bug would add a lot
of complexity to Mozilla, for no net decrease in the amount of time it takes to
get things done on my own computer, while increasing the amount of time it takes
to get things done on public computers.

There are a few things I do often that take multiple keystrokes: getting to a
search engine (alt+home, alt+1), opening prefs (alt+e, e), or opening the
javascript console (alt+t, t, s).  But since I use those keystroke patterns
often, I can use them quickly.  I would not have saved time overall by trying to
find unused Accel shortcuts and binding them to these actions.  If I had also
stared at the keyboard customization dialog and thought "What else do I do
often?", I would have wasted time overall.

When I use a friend's browser (or a public computer), I don't have to worry
about my keys not being set, or worse, that my friend might have changed Ctrl+A
to do something other than "Select All".  I like it that way.  The exception is
that my alt+home, alt+1 for Google doesn't work on everyone's computer, because
not everyone sets their homepage to 
Following mpt's advice, I just filed bug 134614 to make Ctrl+E go to
Ctrl-E is taken, and changing what an existing shortcut does
angers people.  Furthermore, and more to the point for this
bug, you may want a shortcut to get to Google, but I might
not need that, because Google might be my home page, or I
might use a bookmark keyword for searching Google without
loading the search form at all.  Instead, I might want a 
shortcut for toggling page colors, focusing the uabar, or 
some other thing you don't do very often.  

A good set of default shortcuts is an excellent thing, and
I won't argue that Composer is a better default for Ctrl-E
than Google, so I'm leaving your bug 134614 alone, but no
set of defaults, however good, is an adequate substitute 
for customisability.  I would rather have lousy defaults
and be able to change them than have good defaults and be
stuck with them.  (Given the choice, of course, good defaults
and the ability to change them is best of all worlds.)

Regarding your argument about public computers:  the key
bindings should be left at the defaults on such systems,
for reasons that ought to be obvious.  Question is, how
to make it easy for them to be "locked down" so that users
can't fiddle.  I would posit that there should be a separate
rfe to allow an easy way to disable the prefs dialogs 
completely (and re-enable them by removing one line from
prefs.js) for such situations.  Then administrators of
public systems (such as myself) could lock down the prefs,
preventing J. Random User from changing them.  If this is
already extant, it should be documented more prominently.

Users who don't want their own bindings to differ from those
of public systems using the defaults can refrain from 
rebinding their keys, using the defaults.  Users who don't
use public systems can rebind to their hearts' content.
Everybody's happy.  
Another note:  this doesn't necessarily need to end up in the prefs
dialog, if the concern is cluttering the prefs with too many advanced
things.  It would be okay with me if I had to go to xulplanet and 
download it and install it, thereby creating a new menu item to bring
it up and use it.  

Regarding comment 23:  what Emacs uses is more complicated and involves
the way lisp's fundamental data structures work.  In particular, the 
distinction between buffer-local versus global, combined with the
concept of major and minor modes, makes it different from any way it 
could be done in Mozilla (as Mozilla now stands), I think.  But yes, 
it does use a series of (essentially) tables.  A consequence of this 
is that any keystroke can be made into a prefix keystroke, or not, 
depending on the way things are set up.  

But Emacs takes key customisation to another level, that we probably
don't need in Mozilla.  In Emacs, any key binding calls a function,
even if that function is self-insert-command.  So the user or a 
mode can rebind what _any_ arbitrary key does.  I think Mozilla
only needs to allow bucky combos and function keys to be rebound, 
not _everything_, because unlike Emacs, Mozilla does not aim to 
be a lifestyle choice, with modules for everything from spreadsheets
and web browsing to brewing coffee.  It's mostly a web browser, with
a few other add-ons for things ostensibly somehow related to web 

On the other hand, what Mozilla does need is for individual widgets
to be able to change the bindings of certain keys when they have
focus.  (I think this is already done.)  AFAIK Emacs doesn't do 
that, unless the functions associated with a major mode for a 
certain buffer make explicit checks for it, and that's not object 
oriented.  (Lisp is not an object oriented language.  It's 
list-oriented.  Which is better for what it's used for, but nevermind.)

One solution for public computers: make the keyset switchable.

There should always be "defaults" key profile, which could be enabled with some
hard-wired hotkey or from some easy to access menu.

It would be absolutely nice if I could sit on any Mozilla-enabled box in the
world and type in an address that points to some private webspace I have
somewhere, which would then contain my key definitions (and should probably also
contain my bookmarks, other prefs, etc). If we extend this even further, it
would also write new bookmarks back to that HTTP server. Well, that should go to
another bug anyway (no, I don't have time to submit one).

Just some ideas.

Comment 36

17 years ago
*** Bug 139517 has been marked as a duplicate of this bug. ***
I do not agree with comment #27 from Matthew Thomas that this would be too
complicated for a web browser. The web browser and mail/news are the two
programs I use the most. The more you use a program, the more time you can save
by customizing it to fix your needs.

Jesse Ruderman (comment #32) mentioned that he don't want to worry about if a
friend uses different shortcuts. This is not an issue I think. After all, most
users will stick with the defaults (the average user tends to use the mouse more
than the keyboard), and someone changing Ctrl+A is just ignorant, right? The
configurable key shortcuts feature is for changing shortcuts like Ctrl+PageUp
for tab switching (see bug 136915), not for making the program useless by
changing Ctrl+S or something similar.

Besides, your friend can already change the shortcuts in Mozilla, by editing
some xml files, so that's not an argument not to implement this *good* feature.
I agree with David Tenser that this feature is badly needed.

If there is no such front-end, and you have to remap keyboard shortcuts by
messing with XML, many users that would love to remap their keyboard wouldn't do

Does anybody really believe that ordinary users don't need remapping of keyboard
If so, consider such issues:
- differences between UI conventions on different platforms: MS Windows usally
use CTRL-Tab for navigating between window's frames while in Linux (Gnome) it's
used to switch between widgets (buttons, text fields etc), Mac doesn't have the
F1-F12 keys, etc, etc...
- left-handed users vs right-handed users (e.g bug 136915 discusses switching
from CTRL-PGUP, CTRL-PGDN to CTRL-TAB, CTRL-SHIFT-TAB for tab switching. That
would be a catastrophe for me, because those key combinations are so much harder
for me with a right hand)
- internationalized Mozilla versions which might have slightly varying shortcuts
- internationalized versions of operating systems and different keyboard layouts
(there was a time when keyborad shortcuts in Mozilla conflicted with the ability
to input Polish diacritical characters because with Polish programmers keyboard
layout you type them using ALT-LETTER combination. Can you guarantee that no
single key combination will conflict with any given keyborard layout for any
given language?)

All those issues can't be addressed only by careful design by Mozilla UI team.
There are things you just cannot predict.

And I didn't yet mention that people tend to have personal preferences with
regard to keyboard shortcuts... And those preferences sometimes conflict, which
can be seen in Bugzilla in the form of bugs like bug 136915, bug 108636, bug
134614. Without a frontend for easy remapping of shortcuts, those bugs will just
keep coming and haunting us wasting our energy that could be utilized for
something more important than arguing whether CTRL-E is a good binding for Edit
Page (btw I really _do_ use it more often than a web search, Jesse. You don't
have the power to see what all, or even most users, look like).

Comment 39

17 years ago
*** Bug 150444 has been marked as a duplicate of this bug. ***

Comment 40

17 years ago
batch: adding topembed per Gecko2 document
Keywords: topembed

Comment 41

17 years ago
Your url is broken! 

Comment 42

17 years ago
famtie: it's a netscape internal document.  I don't know if there's a gecko2
spec outside the firewall; I'll ask, but I suspect this is more a planning
document for Netscape resources.

I'm having a bit of a problem understanding how an RFE for a XUL front-end can
be listed as a topembed bug, though.  Any gecko2 people want to clarify?

In case anyone is wondering about status, this bug is still looking for an owner
who's good at XUL UI coding.  I'm very happy to help with the back-end
(including writing new accessors if needed) and getting it all reviewed and
checked in if someone wants to step up and take a crack at the UI.

Comment 43

17 years ago
Turns out the document in question says (I'm sure I'm not revealing any secret
information here): "Produce and document API for changing default key bindings"
and a reference to this bug.  So there's a confusion between an XBL key binding
API (I assume they're not interested in XUL key bindings) and the that this bug
discusses.  There should probably be a new bug filed for the embedding issue of
an XBL key binding API, with some indication of what level of functionality
embeddors expect to see.  I'll talk to Marek about that.
Changing from topembed, to embed, as this is not currently blocking a major
embedding customer.
Keywords: topembed → embed


17 years ago
Blocks: 176349

Comment 45

17 years ago
Bulk adding topembed keyword.  Gecko/embedding needed.
Keywords: topembed


16 years ago
Keywords: access

Comment 46

16 years ago
Not really an embed issue at this time (edt)
Keywords: access, topembed → topembed-


16 years ago
Whiteboard: [feature] → [feature] [T2]

Comment 47

16 years ago
Assign to nobody to make it clear that this will require a XUL person.  (Still
don't understand why a XUL front-end bug is on the embedding feature list, but
my mail messages asking about that have gone unanswered.)
Assignee: akkana → nobody
Is there a documentation on how the backend works and can be used from JS?

Comment 49

16 years ago
johann: see comment 4.

Comment 50

16 years ago
*** Bug 172130 has been marked as a duplicate of this bug. ***

Comment 51

16 years ago
This depends on being able to add and remove XBL key bindings once moz is
already running.  Adding some dependencies which relate to those issues.
Depends on: 51261, 51262, 74416, 89524, 119078, 163023

Comment 52

16 years ago
*** Bug 183400 has been marked as a duplicate of this bug. ***

Comment 53

16 years ago
I believe that customisable keyboard shortcuts are very important, and the
process of unzipping/modifying/rezipping files is somewhat beyond most users.
Personally, the shortcut which gives me most problems is Ctrl-Q. In most of my
other applications, this will close the current window if the application has
multiple windows (such as a browser). I hate the fact that the same key in
Mozilla closes all windows - browser, mail etc. It's not easy to mentally switch
between Ctrl-Q and Ctrl-W depending on which app happens to be running.

Comment 54

16 years ago
*** Bug 196098 has been marked as a duplicate of this bug. ***


16 years ago
Blocks: 129472
*** Bug 203808 has been marked as a duplicate of this bug. ***

Comment 56

16 years ago
From comment #21:

    When defining a key already in use, it should ask user: "Ctrl-T is already
    assigned to 'Open new tab'. Would you like to replace it? [YES] [NO]".

Oh god, please no!  Pop-ups SUCK!  One of Mozilla's most wonderful features
is its ability to limit these damn things.

Comment 57

16 years ago
The popup should only be showed when you are defining a new key combination. 
How else are you going go get a yes/no responce from the user except for a
pop-up window with a question?

Comment 58

16 years ago
The way word and OpenOffice do it is quite nice.  In their
keyboard customization dialogs you select the function to which
you want to bind a key (from a list, by typing the name of it
on the keyboard if you wish), then you hit Tab once and it
takes you to the text box in which you can enter a shortcut.
Once you have entered one, a text label beneath that text box
is updated to display the message "currently assigned to:
functionXYZ".  If the shortcut is not in use, it says
"currently assigned to: [unassigned]".  Also as a response to
the user entering a shortcut, an "_Assign" button becomes
enabled, allowing the user to next type Alt+A to assign the
entered keybinding to the selected function.

After making the assignment, it moves focus back to the list of
functions so that you can type in the name of the next function
that interests you.  You can enter keybinding after keybinding
without having to deal with pop-ups, function keys, arrow keys,
or the mouse!  As much as I dislike M$, and especially most of
the dialogs they've ever created, this dialog is very slick,
and a wonderful UI.

Comment 59

16 years ago
I agree that popups are the very last thing we want.

I also agree with comment 58.  A more systemized UI would negate any confusion
over duplicating a key combination.

Comment 60

16 years ago
from Comment #25 - Dean Tessman:

    The first step here seems to me to be getting the list of available
    commands, as Gerv mentioned before.

This in my experience is the hardest part.  Unfortunately, I have never
spent time actually trying to learn the Mozilla codebase, and flopping
around doing one little thing at a time doesn't seem to have afforded
me much insight into what's going on.  Maybe that's why, or maybe it's
just really darn hard to find these things.

For someone like me, an adequate solution to this problem would be just
to have someone in the know go through and create an actual list of _all_
the key-bindable functions, and what files to edit to change/add them.

Also useful would be a HOWTO on how these key-bindable functions are
created in the first place. (XUL? C++? where for different kinds?)

That said, this solution will probably not be useful to the masses.  But
with all the nifty development tools in Mozilla, I'd think it'd be one
more feature to win that whole community.  Hey, more potential contributers.

Comment 61

16 years ago
from comment #34 - Jonadab the Unsightly One (Nathan Eady):

    I think Mozilla only needs to allow bucky combos and
    function keys to be rebound, not _everything_, because unlike
    Emacs, Mozilla does not aim to be a lifestyle choice, with
    modules for everything from spreadsheets and web browsing to
    brewing coffee.

I strongly disagree with the few comments posters have made along
the lines of this one.  Aside from my shell and editor, I spend more
time in this application than any other.  And it is the only choice
for web browsing that I believe I have (Linux).  And as someone else
already said, I might do function X 200 times a day, where most people
rarely use it.  So there will be no cmd_X, and I'll have to go through
three levels of submenus every time I do it (I actually had this
experience in VisualAge for Java).

Also, regarding the debate of good defaults vs. customizability, there
are _many_ reasons for various people to choose shortcuts that suit
them.  Left-handed mouse users may want to ensure that some of the
functions normally mapped to the left side of the keyboard be available
on the right side.  Some might want to make the shortcuts adhere to
those they learned in another browser.  I personally can't tolerate
any shortcuts for functions I use often that require me to move my
hands from the home keys position (i.e., no arrows, no page up, page
down, etc.).  Another reason I have for some of my choices is that I
tailor almost all the apps I use regularly to use basically the same
key strokes for similar functionality, like search, page up/down, line
up/down, etc.

I suppose I'm rambling, but my main point is that you simply cannot
predict what is most important to each user.  And discounting it is
not a good idea, either. is about to go on a long vacation to the bit bucket
Assignee: nobody → nobody

Comment 63

16 years ago

Comment 64

16 years ago
Are you saying that you're going to flush this bug?
Why not just leave it?  You can't possibly disagree
that keyboard shortcuts in Mozilla are fubar.  Even
if there is no one that can handle this right now,
I can't believe it's so unimportant to merit dumping
it altogether.  This is integral to the UI!  You
absolutely cannot use Mozilla without a mouse right
now, let alone use it comfortably.  In my utopia,
it would be considered completely broken for this
flaw, and I'll wager most anyone who has learned and
loved vi (or Emacs?) would agree with me.

Comment 65

16 years ago
Richard, you might want to look at the status (my bugzilla is still showing it
as open -- is yours different?) and what it says next to the Assigned To field.

Meanwhile, this has become academic because key bindings have regressed; it's no
longer possible to make new XBL custom key bindings even by editing files by
hand. :-(  Adding a new dependency on bug 201011.
Depends on: 201011

Comment 66

16 years ago

I am referring to comment 62, which states: is about to go on a long vacation to the bit bucket is a fake user has been assigned
to handle this bug, and I think that "bit bucket" means
the trash, so I take this post to mean that they are
about to throw this issue (along with any others assigned
to in the trash.

    - richard
no, the *user* "" got thrown in the trash.  That's why all of
"his" bugs got reassigned to "" which still exists.

Comment 68

16 years ago
At the time that announcement was made, this bug was *changed from*
"" to "".  It was changed so that it would
continue to be assigned to an account that was valid. (As you say, the Netscape
account is being discontinued.)  So, the reverse of what you claim is what
actually happened.  Changing the assignment was so that the bug would stay
alive, not so that it would "die".  Hence Akkana's comment to look at the
Assigned To field (and to notice that it's not assigned to "".

Comment 69

16 years ago
[That may be true, but I still think this is actually part of an evil 
anti-keyboard-shortcut conspiracy among, the military-industrial 
complex, and the dictatorship of the proletariat. Someday, all will be 

Comment 70

16 years ago
Web interfaces (and along with them Web Browsers) are increasingly being used
for data entry systems.  One particular "keybinding" is of great relevence, the
backspace = back which in Mozilla is active on the windows platform but doesn't
seem to exist in the Linux version... I can't find any way to diable it. 
Obviously this "keybinding" is inactive when the focus is on a text entry type
of element, but fat fingers are everywhere.  It seems like someone put it there
so Mozilla would act like IE on its own platform.  The problem is there is a
work around you can put in an individual web page to disable the key in IE for
that page, but it doesn't work for Mozilla.  It is imperitive to the future of
Mozilla as a data entry front-end that there be a way to disable the BACKSPACE =
Back "feature".  

Comment 71

16 years ago
It's no problem to disable backspace on the webpage itself.

Use an onkepyress handler. If the key is backspace, do 

Comment 72

16 years ago
Today I set out to assign a shortcut key (or keyboard binding) to the rewrap 
function in Mail. I use Netscape 7.1. From pine I was used to use ctrl-j to 
rewrap long lines somewhat intelligently and rewrap in Mail provides the same 
functionality. It is only really useful when available in a shortcut since it 
is a editing command used while typing and formatting. 

My first assumption that there may be prefs for each keyboard binding. Wrong. 
After some googling I found on a page which explains. Now, I cannot 
find the link. The page mentions 


in res/builtin and shows a way to add custom shortcuts in a separate file whose 
name must then be registered somewhere else. One also has to find which element 
or widget it is to which the command is applied. DOM inspector came to the 
rescue and showed the mail compose window has an "editor" element. The shortcut 
keys for the editor element are assigned in the editor section in 
platformHTMLBindings.xml. DOM inspector also showed the function name to be 
assigned to the keyboad shortcut for rewrapping is "cmd_rewrap". I had found 
out by searching the source code on before and this was good live 
confirmation. I decided to edit platformHTMLBindings.xml directly and just 
added this line 

<handler event="keypress" key="j" modifiers="control" command="cmd_rewrap"/> 

to the editor section in the file. After restarting, it worked somewhat to my 
surprise. In Mail I can now rewrap by typing ctrl-j(ustify). 

Of course, there should be a much easier way to customize shortcuts. 

Blocks: 219203

Comment 73

16 years ago
*** Bug 223005 has been marked as a duplicate of this bug. ***

Comment 74

16 years ago
 I believe a menu to reassign keys it's a basic feature
that mozilla should have. Take a look at any KDE application
and their "Change keyboard shortcuts". It's the most intuitive
way: a list of actions, and you can assign 2 keys to each action.
This way you can maintain the original keybindings and add your
personal keys. The same front-end prevents you from setting 
the same shortcut to 2 actions, saying "You can't set CTRL+BLAH
to "Compose New Message" as CTRL+BLAH is currently assigned to
"Compact Folder".

 I've been waiting for a keyboard-shortcut-changing fronted in
mozilla for about 1.5 years...

 Thanks a lot anyway por the browser itself :)


15 years ago
Blocks: 163993
The default shortcut keys have become so good that I personally no longer see
any use for the ability to customize. Customization would only bring
unconsistency. Removed my vote for this bug.
I disagree. It is matter of offering the user a choice. 
Some people will always be familiar with some settings. At least the ones who
made them. This should be done - see for example comment #74.

Comment 77

15 years ago
I strongly disagree with Comment #75. I'm sitting here with a major spasm in my
right arm between my wrist and my elbow after hours of mousing around the menus
in Composer to perform repetitive functions that could be done in a fraction of
the time and with a fraction of the physical wear & tear if I could just assign
keystroke commands to those functions.

I could understand objections to fixing this bug if it constituted a limitation
on or removal of existing options, such that it would somehow negatively impact
users. But this is not a matter of imposing any such interference with users.
Those who don't need the feature simply don't have to use it.

I don't deny any user his right to allocate his votes as he sees fit, but let's
not confuse that right with the larger objective of making Mozilla more useful.
There is nothing about fixing this bug that would reduce Mozilla's usefulness to
any user, but there is a great deal about fixing it that would increase
Mozilla's usefulness to me, and I suspect to many other users.

Comment 78

15 years ago
I totally disagree with comment #75. Everybody is free to retire voting from a 
given bug at any moment, but trying to convince others that making Mozilla a 
better browser could "bring inconsistency" is quite selfish. Trying to REPLACE 
the mozilla default keys would be bad, but adding the chance to change all 
according to user's needs can be never bad. 
 See you. 

Comment 79

15 years ago
There's also the matter of adding shortcut keys for functions that don't have
any by default. Being able to add shortcut keys for the site navigation toolbar
functions could be handy.

Comment 80

15 years ago
This is about giving the user the freedom to make the system work the way they
want it to - strange to hear anyone argue against this in an OSS setting.

Opera has it: file / preferences / mouse and keyboard. Start typing description
of the function you want to assign and you get a picklist of matches (so you
don’t even need to know function names). You can even assign to a mouse gesture
if you like, and the function can even be a URL call.

Three real-life examples of why central planning is not good enough:

1. re-assigning keystrokes: Googlebar replaces a built-in feature (basic toolbar
search field) and renders it obsolete - yet the hotkey Ctrl+K remains assigned
to the removed function, and can't be used for anything else (by a non-coding

2. re-assigning functions: Googlebar's default hotkey, Ctrl+F12, is a two-touch,
two-hand gesture requiring shift of visual focus to the keyboard and rotation
from the elbow: pretty crude. I spent several hours trying to reassign it by
editing GooglebarOverlay.xul, without success. Strokes I tried were F4, Ctrl+G,
Ctrl+K, and tap on Shift. Problem for most is that they’re assigned elsewhere in
Firebird, and those bindings pre-empt what you specify in the XUL file. Trying
to stop a second tap on F4 from dropping down the history list, I tracked down
and commented out two other bindings (menulist.xml and autocomplete.xml), but
VK_F4 also occurs inside Firebird.exe, which was more than I could deal with.

3. accessing html documents (web or local): I made a sidebar help chart for
customized mouse gestures, but as far as I know I can only get at it by pointing
and clicking a link. In Opera I could assign the URL to a mouse gesture.

With Firebird, I can’t make these simple refinements without becoming a hacker.
With Opera, I’d be done in a minute. If the objective is to provide the best
browser in the world, customization fluency is one of the things which has to be

Comment 81

15 years ago
I'm just going to toss another reason into the fray:

5. There is still an on-going <a
href="">bug 186789</a> that
prevents ctrl-shift sequences from working in a GTK2 setting.  While Windows
users may be all too happy to keep their ctrl-shift sequences (such as
ctrl-shift-c for marking all messages read), linux users using GTK2 can't use
such as the bug has not been fixed.  I'm not all that happy to have to
continually search for the "Mark all read" setting in the menu-bar all the time
when I could much more easily set a new keyboard shortcut to work around the
"feature."  Thus, allowing user definition of alternate keyboard shortcuts would
at least allow some leeway until 186789 gets resolved.

Comment 82

15 years ago
Please stop.  We know that this is a wanted feature.  Nobody ever said it 
wasn't.  That's why this bug is still open.  Unless you have something to 
contribute to how to resolve this RFE, it's already been said.  Patches are 
more than welcome.  The UI isn't the big issue here, the big hurdles are 
things like mentioned in comment 25 and comment 26.
Whiteboard: [feature] [T2] → [feature] [T2] Read Comment 82 before contributing

Comment 83

15 years ago
"nobody ever said it wasn't" - see 27, 32, and 75: all arguing that
remappability is either unneeded or bad, and that the RFE should be killed; and
34, arguing that  limited remappability is enough. The issue appears to be open.
This bug is not for arguing (especially with the ghost of mpt ;-) over the
feature requested in the summary.  If the affected module owner, or someone with
higher authority, said "no way, we don't want this fixed" and WONTFIXed the bug,
it *still* would not be the place to argue with that decision.  But since there
has been no such decision, and since Dean and others, including me, are in favor
of this bug being fixed, please stop spamming it with advocacy arguments.

The way to go here is to find someone who can fix this bug and persuade him or
her to take assignment of it.


Comment 85

15 years ago
> The UI isn't the big issue here, the big hurdles are 
> things like mentioned in comment 25 and comment 26.

While that is true, if someone stepped up to write the UI portion, they could
start with something that looked at the key binding files and wrote out to those
files (requiring a restart before the new key bindings take effect).  That would
get many users most of the way there (as long as they have write permission on
the key binding files, which is a requirement anyway until/unless the
userBindings.xml bug 201011 is fixed); and if there was a UI volunteer it would
increase motivation for backend people to figure out how to expose things like
existing key bindings.

Comment 86

15 years ago
Created attachment 138480 [details]
chrome files using keybindings

I've looked into this a little - my big thanks to anyone who gathered almost
all keybindings from UI XUL files (if I remember it well :) to the toolkit XMLs
(probably only inspector and messenger modifies some of them for their specific
usage). If anyone is interested (or just wants to start somewhere) here is the
list of chrome files which use keybindings. I've searched for phrase
'event="key', but it's some time I've last played with XU/BL so I wouldn't be
surprised if I missed something. (res/builtin/htmlBindings.xml and
res/builtin/platformHTMLBindings.xml not included; don't forget

Some thoughts: A lot of these bindings are almost as pretty as they could be in
this world - the key is defined as 'keycode' attribute on <handler>. But a lot
of them are nasty - the key is distinguished in JavaScript code inside
appropriate <handler>. This has to be analyzed to get things sorted. I don't
like the idea of rewriting chrome files but that depends on someone actually
implementing this bug (don't expect me learning C). Either way - please store
somewhere original bindings before rewriting them with the new ones ^_^

Comment 87

15 years ago
Hrm... I knew it. Everytime you finishe something there's a lot more you didn't
see before. So I'm taking my words back - if I understand it correctly it's as
messy as ever before. I've got confused by the fact that some keybindings in
searched files actually do something in browser etc. All relevant bindings (read
"what most people would change") are defined in DTD files. Because it should be
customizable by translators. So... *deep breath* We need some "overlay"
mechanism for XBL bindings, for DTD files, for XUL files... Anybody still
wondering Mozilla has no customizable keybindings?

I'm not a programmer but with so big diffuseness of things we need to keep track
of I don't believe it's possible to figure out how to get all this together. Am
I missing something? ^_^" Toolkit bindings need own mapping (and one must dig
into the code to actually find out what it is supposed to do), XUL bindings are
partly defined in DTD (under rather descriptive names) and partly inside XUL
files themselves. If we want to expose bindings to the user we would evidently
need to keep separate list of descriptions for bindings and their mapping to
approprite files and every change in chrome should have been reflected in this
list... No, it can't work. If there was a plan for customizing keybindings I
don't see it.

If I should have to create customizable layer over this I would mark elements in
XML itself as customizable, by some link-like attribute, and would keep track of
user changes to the default behaviour. User bindings having precedency. Sounds
like adding another layer between keyboard and XUL... Tell me there was a plan
some years ago...

Sorry for the spam. I hope more then three year old bug with 54 votes deserves
some "catharsis"...

Comment 88

15 years ago
*** Bug 233351 has been marked as a duplicate of this bug. ***

Comment 89

15 years ago
*** Bug 240316 has been marked as a duplicate of this bug. ***
*** Bug 234963 has been marked as a duplicate of this bug. ***


15 years ago
Summary: front end for remapping keyboard shortcuts (user-defined keys) → front end for customizing keyboard shortcuts (user-defined keys)

Comment 91

15 years ago
The keyconfig extension offers this functionality for Firefox.  It's a little
rough, but it's a start.

Comment 92

15 years ago
(In reply to comment #91)
> The keyconfig extension offers this functionality for Firefox.  It's a little
> rough, but it's a start.

Thanks, Dean. I'll check it out. You're right, of course...anything is better
than nothing. Too bad it has shown up in Firefox, where there is a complete
separation from the editor function -- either in Composer or in the mail
composer. In fact, that's what has driven my request for this feature from the
get-go. But I won't belabor the point; all the arguments in favor of this bug
have already been made.

Again, thanks for the heads up.


15 years ago
Summary: front end for customizing keyboard shortcuts (user-defined keys) → front end for customizing keyboard shortcuts (configurable/user-defined keys)

Comment 93

14 years ago

does not work. Is there a new method to customize, for example, the navigation
keys in a textbox? If you create a new xbl binding that extends from the default
textbox and add a keypress handler for a key that is already bound for the
textbox, shouldn't it be overridden?

<binding id="binding1" extends="chrome://global/bindings/textbox.xml#textbox">
<handler event="keypress" key="y" modifiers="control" command="cmd_paste"/>

But alas, it doesn't.

Comment 94

14 years ago
*ahem*. my bad. the above URL does work to customize bindings. I'll crawl back
in my hole now.

Comment 95

14 years ago
I am excited that this is being discussed.  I would love to be able to reassign
control-o to open a new page and control-n to open a new tab.   

Comment 96

14 years ago
*** Bug 248895 has been marked as a duplicate of this bug. ***

Comment 97

14 years ago
*** Bug 251871 has been marked as a duplicate of this bug. ***

Comment 98

14 years ago
For me, the greatest obstacle to adopting Thunderbird & Firefox
as opposed to sticking with Mozilla is the lack of consistent 
keyboard shortcuts.  My fingers "know" that Ctrl-N opens a new 
browser window, and Ctrl-2 opens the E-mail window (in Mozilla).
If /only/ they would do the same thing in Thunderbird and Firefox 
respectively ...

Philip Taylor

Comment 99

14 years ago
 Hello ...

 I'm using mozilla products for a couple of years (firefox and thunderbird did
not exist then :), and I'm waiting since then a way to change the keyboard
shortcuts easily, like all the KDE applications can do.

 What's the status of this bug? It is planned to add a keyboard-remapping UI window?

 Thanks a lot :)

Comment 100

14 years ago
I'm using Fedora Core 3 with KDE 3.4 and Firefox 1.0.2 on a laptop.  I'm not
sure exactly which bit of software is at fault but when I least expect it, the
click and drag effect that can be used with the touch pad on my laptop, sends a
forward or back signal to firefox.  
I'm assuming its a KDE thing that sends Alt + Left/Right so I was hoping that by
changing the key assignement I could stop it jumping back when I'm trying to
scroll down a page.  

Comment 101

14 years ago
Re comment #100: are you sure you haven't installed any sort of "mouse gestures"
package, either in firefox or in kde?  Getting rid of the gesture handling might
be a better solution than disabling those mozilla keys.


14 years ago
No longer blocks: 163993

Comment 102

13 years ago
*** Bug 321497 has been marked as a duplicate of this bug. ***

Comment 103

13 years ago
Can I add mine to this -- lack of consistent and comprehensive key mapping and menu editing is important for user efficiency.

Ability to take the pool of "known commands which have keys mapped to them" and then move them to different menus or add different key combo's for them, and icons.

Microsoft has it (office 2k). Its time Mozilla did, I think.
*** Bug 347907 has been marked as a duplicate of this bug. ***


12 years ago
Duplicate of this bug: 378352

Comment 106

12 years ago
Is this scheduled yet?
I would love to easily customize keyboard shortcuts of thunderbird because im using "the bat!" on windows and would like to use same shortcuts like there...


11 years ago
Duplicate of this bug: 341768


11 years ago
Duplicate of this bug: 415797

Comment 109

11 years ago
@Dean: Is there and documentation for keyconfig extension that a normal human can read? For simple things like scrolling messages in Thunderbird I cannot find any information at all.

I'm actually of the opinion that an extension _is_ the proper way to handle this issue. The bug requests a feature that few users will ever need, however, it is essential to those who need it. That said, I am voting for the bug as it's implementation will make my life quite a bit easier. I have a broken right hand, and as it stands, I cannot use applications that force me to use either the mouse or shortcuts that require two hands.

Comment 110

11 years ago
Dotan, the only documentation I've found is in the MZ thread:

I've never tried it, but the Functions for KeyConfig add-on looks like it can give you the scrolling control that you need.

Comment 111

11 years ago
Thanks, Dean. That is a long thread, but I'm getting there. I do know about Functions for keyconfig and I use it. Thanks.
Duplicate of this bug: 485518

Comment 113

10 years ago
Dorando has keyconfig extension  Ctrl+Shift+F12 available at    should be built-in to Firefox, but would not want to lose any features that the extension has, and just because multiple actions have same keyboard shortcut does not always  mean a conflict.     Allows sorting on Name and sorting on Shortcut.  Buttons for adding a new key, Apply, Disable, Reset.  Conflicting assignments are highlighted on the Shortcut. I've used it for years and it works great had a lot of problems because couldn't update my shortcut changes when Version 3 came out during testing, which a good reason that it should  be built-in. 

Allows you to change any existing keyboard shortcut to another shortcut, or remove a shortcut. [options][tools]   Using default Ctrl+Shift+F12
Not nice to have to change keyboard assignments but was very necessary, the extension is very useful in identifying keyboard shortcut conflicts by sorting on key.    Dorando is alive and replies to questions in the forum, and did update for version 3. 

Documentation exists at: More than was supplied in #91, #92, #110 --
QA Contact: bugzilla → keyboard.navigation


9 years ago
Duplicate of this bug: 541501


9 years ago
Duplicate of this bug: 542750

Comment 116

9 years ago
Is there a schedule for this bug? It's great to have an extension to do change keyboard shortcuts, but the settings dialog is more intuitive. 

The use of web browsers is changing. Years ago they were used mainly for navigating through web pages. In the last few years, text processing got more and more into the browsers, be it in web mail applications, forums or even online office applications. The direction goes to more fields such as image processing, music editing or whatever offered online in the browser.

There is no possible set of keyboard shortcuts that fits for all these kinds of use. The often-cited backspace behaviour is great for navigating through websites, but most annoying for text-processing purposes. The average office user will expect keyboard shortcuts in Firefox to behave as in his/her favorite word processor. A musician might be used to shortcuts of Logic or whatever, a graphic designer to the ones in Adobe products. They all will be most annoyed, if they work in an online application, hit their favorite shortcut, and the browser does something unexpected which might even cause loss of their data.

Additionnally, an import/export function for keyboard shortcut sets would be great for people who work on a lot of different computers, such as freelancers, combined with a "change shortcut set for this session only" option...


9 years ago
Duplicate of this bug: 577507


8 years ago
Duplicate of this bug: 21211

Comment 119

8 years ago
This feature request exists for as long as Firefox exists... actually even longer than that. Watch the dates when some of the (now) "duplicate" bugs have been filed. The main problem is not Fx itself; the developers make sure there are more or less good keyboard shortcuts, usable on every platform (and sticking to platform conventions if possible and those are existing), the problem is that pretty much every second add-on adds new keyboard bindings and I have at least three add-ons, that all three want to use the same keyboard shortcut. There are simply not enough keys on my keyboard to give every one an own shortcut and add-on developers don't make sure their shortcuts don't conflict with other existing add-ons using shortcuts (considering the number of add-ons, that would be pretty much impossible). Further many add-on developers use only one platform themselves and choose shortcut that are pretty awkward if not impossible on other platforms.

This leaves three ugly workarounds for most people:

1. Change bindings by "hacking" around in source or config files.

2. Use an ugly, unreliable extension named keyconfig, that sometimes is willing to work with whatever Fx version you are currently running and sometimes won't get updated for months.

3. Bother the add-on developer long enough, so s/he makes the shortcuts configurable in the add-on prefs, which means partially the same code over and over again, but each time a completely different UI and new bugs and problems.

This is just ridicules, as even tiny freeware apps will often allow you to customize your keyboard shortcuts, aside from pretty much every bigger software package (e.g. LibreOffice of course allows you to customize shortucts). And if there exists an extension that can do it, then Fx should be able to do it as well. Further if there was an official way (API) how add-on developers should register their shortcuts, so that they are customizable and not cause conflicts, I'm pretty sure *ALL* add-ons developers would be more than happy to exclusively use this API. So if it was necessary to rewrite the shortcut handling of Fx and make all people migrate to a new API to make this feature work, this will be the smallest problem.

My expectation is that there is a place in the preferences for customizing the keyboard shortcuts, that lists all existing shortcuts of Fx itself and further all shortcuts registered by add-ons. There should be a "Function Name" per shortcut, a "Short Description", the shortcut itself (might be empty, if unassigned) and all this should be sorted in such a way, that it is clear where the shortcut comes from (if it is from an add-on, it should be clear which add-on, if it is core part of Fx, this should also be clear). This function is missing since the first add-on developer decided that a shortcut for his/her add-on is a good idea.

Comment 120

8 years ago
Please see comments 82 and 84.

This isn't just a Firefox issue. This bug was filed for the Mozilla Suite--long before Firefox existed--and it still affects SeaMonkey as well. 

If you've voted for the RFE, that's terrific, but what's really needed is a solution. As you can see if you read the entire thread, it's not a simple matter...but I'm sure everyone will join me in encouraging you to have at it. Good luck!

Comment 121

8 years ago
@freevito: This bug won't fix on its own and nobody is actively working on it at all for YEARS now. Just FYI, I said Firefox, because my original bug, which was about Fx, has been closed as a duplicate to this bug some day (within the last TEN years where this has been a major unresolved feature request across all Mozilla products). This bug is blocking on issues, that haven't been touched for 3 to 5 years, if they even exist at all as of today. This bug is talking about internal structure that certainly is not the same as it was 5 years ago. "You cannot be better without being different", who said that? Well, doesn't matter, but the last time I heard this sentence, it was from the mouth of a Mozilla developer.

So let's be different then! Lets stop using the crappy XUL ways of how keyboard shortcuts have been done the last 10 years and lets solve the issue *at its root*. They way how this system was designed is flawed, broken by design, and there is no way to fix it. If you cannot fix it, drop it! That is, replace it with a different system that works. Don't waste time on hacking nifty, but ugly workarounds for a problem that wouldn't even exist if you'd just do it RIGHT(tm).

Do you know Komodo Edit or the Komodo development suite? It is based on XUL. Give it a try, the editor is free:
Even though it is based on XUL, all keyboard shortcuts, be it shortcuts of the editor or of the menu or of some plugin, they are all customizable (some only take effect after a restart of the application, but they are customizable; they even show correctly in the menu after a restart). So why can they do it and other XUL apps cannot?

If some major redesign of all keyboard handling code, a new central API or dispatcher, is necessary in the XUL framework, so be it. Then lets start planing and discussing one, then implementing it and finally merge it into the existing code base, so we can start moving all keyboard handling to it. However, this won't happen if we sit here, twiddle our thumbs and wait another ten years for this bug to magically fix on its own. Since 2005, about once every 6 month or so some other bug was resolved by making it a duplicate of this one or one or two more or less useful comments have been posted and other than that, there was exactly *ZERO* progress on this issue. So how many more years have to pass, before only a tiny step is made by anyone towards resolving this bug?

Comment 82 was **SEVEN** years ago and what has been suggested in comments 25 and 26 has not happened as of today and is actually a complete waste of time, since it is not necessary to solve this issue at all. Feel free to keep pointing to comment 82 another decade, but I'm looking for someone who really seriously wants to work on this issue, instead of living 7 years in the past (no offense intended).

And for whomever this is too much noise on a 10 year old bug, unsubscribing of this bug is just one click away.

Comment 122

8 years ago
@TGOS  I don't take any offense whatsoever. I'm sorry that the meaning of my post wasn't clear. I'll try to state it more simply.

I'm sympathetic toward your frustration with the still-unresolved status of this bug; after all, I voted for it too. I agree completely that the bug will not resolve itself. But neither will venting about it. (No offense intended.)

In fact, I appreciate your passion, and I hope that you will turn it to productive use. The assignment status at the head of this page says "Assigned To: Nobody; OK to take it and work on it". Evidently, for the past 10 years, Bug 57805 has been waiting for you to come along and take ownership. I'm sure the other folks who voted for it will appreciate your successful efforts.


8 years ago
Duplicate of this bug: 635717

Comment 124

8 years ago
Before I change to FF4 I'd like to know whether this feature request is solved in FF4 or whether keyconfig still works under FF4 when compatibility is adjusted.
Can anybody tell?
Bege, a quick check and I don't see the ability to customize the key bindings in Firefox 4.0 with the Keyconfig extension. In a rush otherwise would look further in to it for you.

Comment 126

8 years ago
Everybody: It is possible to edit keybindings in FF4:

Quelitu people (<a href="">an operating system for upgrading/recycling old computer... and for new ones too</a>) have a solution to configuring keyboard keys.

Go to this page and scroll down to:
<a href="">Edit Firefox 4 (FF4) Keybindings / Keyboard Shortcuts / Keyconfig Alternative</a>

Let me know if this helps.
I just filed bug 673669 for one narrow part of this wider issue.


8 years ago
Duplicate of this bug: 676210

Comment 129

7 years ago
Is there a simple way to solve ?


3 years ago
Blocks: 851504
What's the status of this issue? With the advent of WebExtensions, there is no longer an extension that will provide this functionality.
Blocks: 1215061

Comment 131

7 months ago
18 years... This used to be able to be fixed with addons but since the new API is not good enough, we lost this ability. Any chances we can get this features between now and the next 18 years?

Comment 133

7 months ago
At least for some keys, you can still change (at least some) key bindings in quantum by modifying omni.ja. I documented some steps:
Gentle reminder that comments are not for berating one another. 

The WebExtensions team is aware of what's being asked for and that work is being tracked in bug 1215061.

Comment 135

3 months ago
It would be useful to also include the customization of mouse keybindings (e.g. double click, wheel scroll etc.).

I hope this feature gets implemented before XBL is removed. At least for now we have UserChrome+XBL and still "" helping us power users workaround the questionable decisions of Mozilla in recent years.

Hopefully when "" something at least equaly customizable will replace these technologies and the user customizable bindings are a necessary part of such replacement. Well, false hopes are better than no hopes I guess.
You need to log in before you can comment on or make changes to this bug.