User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Contrary to documentation (http://mozilla.org/unix/customizing.html#keys), it is
not possible to customize key-bindings. Nor is possible to even turn off the
pre-defined ones. This is a regression and a serious deficiency for editing in
the composer. Please see the following discussion for specifics.
Steps to Reproduce:
1. Try to customize key bindings as documented.
2. Restart Mozilla.
3. Notice that bindings do not take effect.
Default keybindings were still in effect.
Mozilla should have respected my customization.
Do we fastload things like this?
Confirming and changing platform to all -- it's a problem on linux too.
Apparently bugzilla doesn't actually reassign or confirm when a Product change
is involved. Trying again.
Don't assign this to me if you want it fixed any time soon.
Somebody needs to take this a little more seriously. Its hard enought to remap
key bindings normally.
I've been unable to remap Browser:Open or Browser:OpenFile.
Now its completely broken. Please assign this to someone who can fix it!
Apparently bryner changed something that might have horked keybindings.
Another probably related key binding problem that regressed at roughly the same
time: when I start up mozilla, the platform key bindings no longer work in the
urlbar. After I visit a url, they start working again (I think I've seen them
break again later, but I'm not sure about that).
Akkana: which checkin are you referring to? (I know of a few candidates)
I was hoping you could tell us. I don't know what horked key bindings a few
months ago, and we're all looking for someone who might know. Your name was
For anyone tracking this: Modifying the installed
res/builtin/platformHTMLBindings.xml seems to work for me in NS7.1/Linux (I'll
try it asap in more recent mozillas and other platforms). I've updated the
customizing document to say so and to point to this bug re the currently
nonworking userHTMLBindings.xml instructions.
This was always intended to use a file in the user's profile directory
somewhere, not in $appdir/res/builtin where the fixed binding files are, so I
hope that if this is fixed, it can be fixed that way.
Bug 108417, bug 68950, and bug 12911 said that there would be a resource: url to
refer to files in the user's profile, but I can't find anything like that in
nsResProtocolHandler.cpp, and bug 137006, implementing relative prefs for mail
profiles, seems to use strings like "%Profile%ImapMail/imap.mail.netcenter.com"
then use nsPrefBranch::GetComplexValue(). The parsing code may be in
NS_GetPersistentFile(), but that lives inside mailnews so it's not much help to
anyone else. Conrad (cc'ing), what's the approved way of doing this now, and is
it documented anywhere?
modifying platformHTMLBindings.xml does *not* work for me on WinXP.
does not work for me on MacOS Tiger.
both using Firefox 1.0.7
(In reply to comment #12)
> modifying platformHTMLBindings.xml does *not* work for me on WinXP.
> does not work for me on MacOS Tiger.
I used to edit [...]/res/builtin/userHTMLBindings.xml and it worked very well.
That doesn't work on the newer Mozilla and Seamonkey builds either. The last
working build I have is from June 14 2005.
*** Bug 314099 has been marked as a duplicate of this bug. ***
In recent versions of Firefox (1.5RC1) platformHTMLbindings.xml was hidden away in toolkit.jar.
In 1.5RC2 it has totally vanished. No way to fix that anymore. No way to do per-user bindings anyway. Nothing in the releasenotes, too. Could someone dig into that problem and smack the developers responsible for this silent breakage over the head, please? With an IBM Model M keyboard?
Really, this is the worst regression I had with Firefox for a long time.
> was hidden away in toolkit.jar.
More precisely, it was moved to toolkit.jar to fix bug 296764 (which was that if JS is disabled the whole file had no effect at all).
> In 1.5RC2 it has totally vanished.
I still see it in toolkit.jar in the Linux version of 1.5RC2...
(In reply to comment #16)
> > was hidden away in toolkit.jar.
> More precisely, it was moved to toolkit.jar to fix bug 296764 (which was that
> if JS is disabled the whole file had no effect at all).
Interesting... Would be even more important then to a) make sure platform-specific bindings work out of the box (like the Emacs bindings in OS X) and b) allow user-specific bindings (since fiddling around in toolkit.jar is not a thing a user should be forced to do).
> > In 1.5RC2 it has totally vanished.
> I still see it in toolkit.jar in the Linux version of 1.5RC2...
Yes, I was just plain wrong here, sorry.
See also the mozillazine knowledge base wiki, which details how to install custom key bindings system-wide in newer versions of Firefox: http://kb.mozillazine.org/Emacs_Keybindings_%28Firefox%29
As the original reporter of this issue, I have to report that I have installed XKeymacs (as suggested above) on all my Windows systems, and it has been quite satisfactory at resolving my main complaints regarding Firefox bindings (as well as improving my entire experience with Windows).
I wanted to reconfigure some of the keybindings, I've followed the kb article, unfortunately there's not toolkit.jar on my system.. maybe it's because I'm using Iceweasel from Debian?
Or is the kb article no longer true for FF 184.108.40.206
Any update on the status?
This would be extremely valuable for a lot of us.
Been broken a loooonnnggg time...
See also comments in #314099
I stumbled onto this bug after I began to use Emacs as my editor every day. I found myself searching in FF by typing /search_string and then ctrl+g for repeating the query down through the document.
Well, in Emacs, ctrl+g quits whatever command you have begun to write in the mini-buffer. In Emacs, I use ctrl-s for searching and repeating the search. In Firefox, that saves the file, which I don't do very often.
The bottom line is that two of my favorite programs which I use all day each day are causing me grief because their key-bindings are different.
I turned on emacs key-bindings in gnome using this:
gconftool-2 --set /desktop/gnome/interface/gtk_key_theme Emacs --type string
I got that tip here:
Still, it's not enough. I need full control of all the key-bindings.
I've inadvertently sent form content into oblivion more than once with CTRL-W (blame emacs...). Although a 'warn before closing' feature might be nice, it seems like the key bindings are really the underlying issue. Sure would be nice to have a straightforward front-end to specify firefox key bindings... rather than a mish-mash of ui.key.foo prefs, mods to .gtkrc-2.0, edits to various xml files buried here and there, etc...
Mass un-assigning bugs assigned to Aaron.
This section seems woefully out of date - most of the files referenced no longer exist
I managed to successfully change my key bindings using the keyconfig extensions:
There's an extension called 'keysnail' which allows very fine grained control and a wealth of other functionality for adjusting keyboard controls for your Firefox sessions. It's geared toward emacs users but is excellent for general customization.
For a tweaked out starting point (disclaimer: not mine, and YMMV) check out https://github.com/re5et/.dotfiles/blob/master/.keysnail.js
(In reply to Greg Engel from comment #25)
> This section seems woefully out of date - most of the files referenced no
> longer exist
For native custom keybindings in for example SeaMonkey 2.12.1...
1) build from source (e.g.https://developer.mozilla.org/en-US/docs/Simple_SeaMonkey_build)
2) add handlers for bindings to objdir/mozilla/dist/bin/chrome/toolkit/content/global/platformHTMLBindings.xml
(This assumes you have mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/objdir in .mozconfig when building.)
My vaguely vi/unix-ish customizations for platformHTMLBindings.xml are...
<handler event="keypress" key="k" command="cmd_linePrevious" />
<handler event="keypress" key="j" command="cmd_lineNext" />
<handler event="keypress" key="h" command="cmd_charPrevious" />
<handler event="keypress" key="l" command="cmd_charNext" />
<handler event="keypress" key="b" modifiers="control" command="cmd_movePageUp"/>
<handler event="keypress" key="f" modifiers="control" command="cmd_movePageDown"/>
<handler event="keypress" key="0" command="cmd_moveTop"/>
<handler event="keypress" key="g" modifiers="shift" command="cmd_moveBottom"/>
And in platformNavigationBindings.xul I use...
<key key="n" command="cmd_newNavigatorTab" modifiers="control"/>
<key key="c" command="Browser:Back" modifiers="control"/>
<key key="d" command="cmd_close" modifiers="control"/>
<key key="o" command="focusURLBar"/>
<key key="m" oncommand="handleURLBarCommand('none',event);" modifiers="control"/>
Note well: SeaMonkey (2.12.1) somehow caches these files, so changes to them only "take"
effect under special circumstances. I don't know the correct way to trigger "recaching".
The method I use that works is to first execute a much older SeaMonkey version (i.e. 2.1b1.)
After more than 10 years, there is still no solution to disable Ctrl+Q without installing 3rd party software or FF extension.
I think we should switch to Chromium browser.