Open Bug 201011 Opened 21 years ago Updated 11 months ago

custom key bindings no longer possible

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P5)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: khamilton, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: helpwanted) 

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.
Do we fastload things like this?
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
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
Blocks: 57805
Don't assign this to me if you want it fixed any time soon.

Any takers?
Keywords: helpwanted
Keywords: regression
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).
Assignee: aaronl → bryner
Keywords: nsbeta1
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
suggested.
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-
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.
Assignee: bryner → aaronleventhal
Priority: -- → P2
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
(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. ***
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 2.0.0.7
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:
http://kb.mozillazine.org/Emacs_Keybindings_(Firefox)

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.
Assignee: aaronleventhal → nobody
QA Contact: bugzilla → keyboard.navigation
http://www.mozilla.org/unix/customizing.html#keys

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:

http://forums.mozillazine.org/viewtopic.php?t=72994
http://pqrs.org/firefox/extensions/functions_for_keyconfig/index.html#t0p1
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
(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.)
Component: Keyboard: Navigation → User events and focus handling

Considering this old archived documentation, I will assume that there may have been changes on this part of the browser (custom key bindings).
@hsinyi, do you think you could redirect me to some more up-to-date documentation or someone who has extensive information on this area?

I would like to re-confirm this bug, part of the Open Major Bug triage, or close it if key binding customization is working as intended.
Can you help me?

Flags: needinfo?(htsai)

This is definitely still a problem, and has gotten worse in the last few years. For quite a while, it was at least possible to set or disable some of the hardwired key bindings by unpacking omni.ja, modifying browser-sets.inc and re-packaging omni.ja. But sometime around late 2018/early 2019, those files got reorganized and I have never found a way since then to customize or remove any key bindings, especially that Ctrl-W which is forever losing work by closing tabs unexpectedly as described by David A Thompson in comment #23. Sometimes Ctrl-W deletes the last word, sometimes it closes the tab, depending on what component has focus, and I've found no way in current firefox to prevent that tab-closing behavior.

Flags: needinfo?(htsai)

But sometime around late 2018/early 2019,

I think that it's related to bug 1550058 or something which moved shortcut key definitions from XUL. Currently, there is no strict way to customize shortcut keys which are defined by C++ code because:

  1. The most preferred command for a key combination is, firstly registered in the shortcut key chain.
  2. There is no way to remove/update registered shortcut keys.

However, there is a hacky way to override existing shortcut keys, that is, build-in shortcut keys are handled at keypress (which is always fired internally even if non-printable key combination), but XUL <key> element can be defined with event="keydown". Then, it's handled at keydown event which is a preceding event of keypress event. However, this may override some other key event handlers such as add-ons, autocomplete, etc and some web apps which Gecko dispatches non-printable keypress events for the backward compatibility (these prefs may be updated without updating Firefox version).

Ah, so, the definition files were removed by the changes. Therefore, customizing any files does not help due to no users...

Reconfirming this bug based on the last 3 comments.
If further testing is required on this part, detailed documentation of what needs to be done should be provided.
FYI: We don't have basic information on how this should work in the first place.

Severity: major → S2
status-firefox97: --- → affected

Currently, shortcut keys are stored internally using a forward linked list of KeyEventHandler class which is managed by GlobalKeyListener. Although the scan of looking for updating shortcut key is slow, but this simple structure makes the startup performance better. So perhaps, adding new API of updating shortcut key via command or <key> element is the first step.

S3/P5 for customized behavior support.

Severity: S2 → S3
Priority: -- → P5

The severity field for this bug is relatively low, S3. However, the bug has 61 votes and 64 CCs.
:hsinyi, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(htsai)
Flags: needinfo?(htsai)

I concur the severity of the bug should be increased. Several times a week I lose work because of the Ctrl-W reason mentioned in comment 23.

You need to log in before you can comment on or make changes to this bug.