Note: There are a few cases of duplicates in user autocompletion which are being worked on.

custom key bindings no longer possible

NEW
Unassigned

Status

()

Core
Keyboard: Navigation
--
major
15 years ago
a year ago

People

(Reporter: ken hamilton, Unassigned)

Tracking

(Blocks: 1 bug, {helpwanted, regression})

Trunk
helpwanted, regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

15 years ago
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.

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=3E8DF29F.8040309%40netscape.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26group%3Dnetscape.public.mozilla.editor

Reproducible: Always

Steps to Reproduce:
1. Try to customize key bindings as documented.
2. Restart Mozilla.
3. Notice that bindings do not take effect.
Actual Results:  
Default keybindings were still in effect.

Expected Results:  
Mozilla should have respected my customization.

Comment 1

15 years ago
Do we fastload things like this?

Comment 2

14 years ago
Confirming and changing platform to all -- it's a problem on linux too.
Component: Composition → Keyboard: Navigation
OS: Windows 2000 → All
Product: MailNews → Browser
Hardware: PC → All
Summary: key bindings no longer possible → custom key bindings no longer possible

Comment 3

14 years ago
Apparently bugzilla doesn't actually reassign or confirm when a Product change
is involved.  Trying again.
Assignee: ducarroz → aaronl
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: esther → sairuh

Updated

14 years ago
Blocks: 57805

Comment 4

14 years ago
Don't assign this to me if you want it fixed any time soon.

Any takers?
Keywords: helpwanted

Updated

14 years ago
Keywords: regression

Comment 5

14 years ago
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!

Comment 6

14 years ago
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).
Assignee: aaronl → bryner

Updated

14 years ago
Keywords: nsbeta1
Akkana: which checkin are you referring to? (I know of a few candidates)

Comment 8

14 years ago
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
suggested.

Comment 9

14 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 10

14 years ago
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.

Updated

13 years ago
Assignee: bryner → aaronleventhal
Priority: -- → P2

Comment 11

13 years ago
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?
Priority: P2 → --
modifying platformHTMLBindings.xml does *not* work for me on WinXP.

modifying
/Applications/Firefox.app/Content/MacOS/res/builtin/platformHTMLBindings.xml
does not work for me on MacOS Tiger.

both using Firefox 1.0.7

Comment 13

12 years ago
(In reply to comment #12)
> modifying platformHTMLBindings.xml does *not* work for me on WinXP.
> 
> modifying
> /Applications/Firefox.app/Content/MacOS/res/builtin/platformHTMLBindings.xml
> 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. ***

Comment 15

12 years ago
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.

Comment 16

12 years ago
> 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...

Comment 17

12 years ago
(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.

Comment 18

12 years ago
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
(Reporter)

Comment 19

10 years ago
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).

Comment 20

10 years ago
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 2.0.0.7

Comment 21

9 years ago
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

Comment 22

9 years ago
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:
http://kb.mozillazine.org/Emacs_Keybindings_(Firefox)

Still, it's not enough. I need full control of all the key-bindings.

Comment 23

8 years ago
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.
Assignee: aaronleventhal → nobody
QA Contact: bugzilla → keyboard.navigation

Comment 25

7 years ago
http://www.mozilla.org/unix/customizing.html#keys

This section seems woefully out of date - most of the files referenced no longer exist

Comment 26

7 years ago
I managed to successfully change my key bindings using the keyconfig extensions:

http://forums.mozillazine.org/viewtopic.php?t=72994
http://pqrs.org/firefox/extensions/functions_for_keyconfig/index.html#t0p1

Comment 27

6 years ago
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.

See https://github.com/mooz/keysnail/wiki

For a tweaked out starting point (disclaimer: not mine, and YMMV) check out https://github.com/re5et/.dotfiles/blob/master/.keysnail.js

Comment 28

5 years ago
(In reply to Greg Engel from comment #25)
> http://www.mozilla.org/unix/customizing.html#keys
> 
> 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
and/or objdir/mozilla/dist/bin/chrome/comm/content/navigator/platformNavigationBindings.xul

(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.)
Comment hidden (advocacy)
You need to log in before you can comment on or make changes to this bug.