Open Bug 72352 Opened 24 years ago Updated 3 years ago

Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] (Ctrl+W doesn't close empty tabs)

Categories

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

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

Tracking

()

People

(Reporter: maolson, Unassigned)

References

Details

(Keywords: helpwanted, Whiteboard: se-radar)

Attachments

(1 file)

Keybinding suggestions
946 bytes, text/plain
Details
I'd like to be able to turn off emacs keybindings, and I think others might as well. Most obvious to me is <ctrl>w, which will no longer close a window when focus is on a textfield. Rather than editing the bindings files, I'm going to investigate using a pref to control this behavior. There has been mention that there are potential performance problems here, so any proposed solution will need to have minimal impact with or without the pref set.
Status: NEW → ASSIGNED
*** Bug 75685 has been marked as a duplicate of this bug. ***
i would like to nominate to the owner or submitter of this bug to change the platform to All & the OS to all. i am a mac & windows (& linux, too) user who prefers emacs key-bindings. i think there are many emacs users out there on various platforms/OSes who would like this as a cross-platform preference. a minor issue.
*** Bug 64828 has been marked as a duplicate of this bug. ***
*** Bug 87643 has been marked as a duplicate of this bug. ***
*** Bug 84755 has been marked as a duplicate of this bug. ***
*** Bug 84168 has been marked as a duplicate of this bug. ***
Right. There should not just be a way to turn them off, but to turn them entirely on - for example, the resolution to bug 51570 was to make ctrl-W always try to close the window, when in a mail compose window. This is dangerous behavior for someone who is used to the emacs keybindings. So, whatever else the pref does, it should make sure ctrl-W never means "close" when emacs keybindings are on, and always means "close" when they are off.
*** Bug 114831 has been marked as a duplicate of this bug. ***
Just a note: the emacs bindings are XBL bindings (and therefore user settable, but not changeable at runtime). The window bindings are XUL bindings, and therefore coded in the jar files and not overridable. A solution to this bug would require that someone write code that bridges the gulf between XUL and XBL bindings, and, probably, enable XBL if not XUL bindings to be changed at runtime (since prefs currently aren't read until after the bindings have already been read). Alternately, doing away with XUL bindings altogether and using XBL would also make this easier to solve (though the change-at-runtime thing would still be required if the change is to use a pref rather than userChrome.xml). I'd love to see it happen, but it's probably going to require some tricky surgery deep within the key/event handling code. Just so you know what you're getting into. It's all completely XP code, and it would be extra work to make it unix-only, so I'm taking the liberty of changing platform to all; if the bug's owner doesn't agree, please accept my apologies and change it back.
OS: Linux → All
Hardware: PC → All
*** Bug 115300 has been marked as a duplicate of this bug. ***
*** Bug 116781 has been marked as a duplicate of this bug. ***
*** Bug 118551 has been marked as a duplicate of this bug. ***
updating summary/status so that i can query on this more easily.
Summary: Make emacs textfield keybindings a pref → Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix]
Whiteboard: se-radar
*** Bug 118739 has been marked as a duplicate of this bug. ***
*** Bug 119696 has been marked as a duplicate of this bug. ***
*** Bug 142250 has been marked as a duplicate of this bug. ***
*** Bug 147072 has been marked as a duplicate of this bug. ***
*** Bug 149581 has been marked as a duplicate of this bug. ***
Attached file Keybinding suggestions —
With reference to comment #9: As an emacs user I don't care whether I get emacs keybindings via an XBL, XUL, XWY, or XQREXE binding. As things are now, I'm not clever enough to get them under any system. How about having a program that displays all the possible things you do with keybindings. This could allow you to check that you like emacs, vi, openoffice, ... and would then set up defaults for those. But then the user could click on on one of the items and hit a key combination that would be used for that action. When the user clicks on all done, the appropriate configuration files are written and if necessary mozilla is shut down and restarted, or to simplify life for the developers the program could just tell the user to do this. To one who is ignorant of the internals of what it would take to implement this, it seems that it might be done without changes to existing Mozilla code as this would just sit off on the side.
*** Bug 140119 has been marked as a duplicate of this bug. ***
Summary: Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] → Make emacs textfield keybindings a pref [aka, conflicting key bindings on linux/unix] (Ctrl+W doesn't close empty tabs)
*** Bug 196450 has been marked as a duplicate of this bug. ***
Emacs keybindings, specifically ctrl-a, ctrl-e and ctrl-k should be implemented by default in OS X, as all native apple apps (including safari) are able to take advantage of these key bindings. i'm not positive of what other keybindings they support.
Todd: Please file that as a separate bug and cc me. If you can talk the mac UI folks into it, I'll volunteer to attach a patch implementing it (that's the easy part, getting consensus is the hard part) . It's not part of this bug, however.
*** Bug 218889 has been marked as a duplicate of this bug. ***
*** Bug 203428 has been marked as a duplicate of this bug. ***
*** Bug 217316 has been marked as a duplicate of this bug. ***
*** Bug 216930 has been marked as a duplicate of this bug. ***
Bug 119696 has been marked as a duplicate of this bug.
*** Bug 222247 has been marked as a duplicate of this bug. ***
*** Bug 226355 has been marked as a duplicate of this bug. ***
Blocks: 189615
Assignee: maolson → aaronleventhal
Status: ASSIGNED → NEW
QA Contact: bugzilla
Keywords: helpwanted
*** Bug 221901 has been marked as a duplicate of this bug. ***
Proposal: 1. If Mozilla is running on top of Gnome (if we can detect that), follow the Gnome emacs key binding pref that's already in Gnome. 2. Otherwise, keep the same behavior we have now. Mozilla should try to fit into the environment it's running on. If the emacs bindings are working on the rest of the desktop, Ctrl+A should go to the beginning of a line. If the rest of the desktop is using Ctrl+A to select all, Mozilla should do that. In my mind this is similar to the bug where we don't follow the Mac OS X tab navigation prefs. Issues: - Can we detect if Gnome is running in an efficient manner? - Does KDE have a similar pref that we can use if it's running?
I've reached a little mini-consensus on IRC that we should always just look gtk setting. 1. If "gtk-key-theme-name" is present in a Gnome rc file (pointed to by GTK_RC_FILES), use Emacs bindings if set to "Emacs" 2. else otherwise follow current behavior (which is to use Emacs bindings) Users of any environment can edit that setting, whether they use Gnome or not. Objections or comments?
Brian Ryner mentioned that Mozilla can use the gtkrc interface instead of looking for the file ourselves.
Then the emacs set could have some of the bindings that are currently turned off, like ctrl-W for word erase in the editor window. Hooray! There's a key theme in .gtkrc-2.0. Is there one in 1.x? This might only be feasible in gtk2 mozilla builds. Checking the gtk2 pref and not a kde pref is probably reasonable given that mozilla has always been a gtk app (if we ever get a qt build, then that can be revisited). Using the gtkrc interface rather than reimplementing that code definitely sounds like a good idea, since then we don't have to worry about things like gtkrc files including other files. Is "Emacs" the only gtk key theme which implements these bindings? Of course, people who use custom themes and don't name them "Emacs" will have no recourse for mozilla. :-( I suppose ideally we'd check the gtk key theme and also allow the user some way to set those bindings within mozilla. Be aware of bugs 164638 and 89524 (which I think are dups of each other?). It may or may not be possible to change XBL key bindings after startup (those bugs apply to the accel key pref, not to the bindings themselves).
(In reply to comment #35) > Then the emacs set could have some of the bindings that are currently turned > off, like ctrl-W for word erase in the editor window. Hooray! Yes, it goes both ways. By having a separate platformHTMLBindings.xml for emacs we can have a clean separation instead of playing a game where we try to support both at the same time (and not playing it that well). We'll need a volunteer to separate the current unix file into 2 platformHTMLBindings files. I envision it being in mozilla/content/xbl/builtin/emacs (as opposed to mozilla/content/xbl/builtin/unix). > There's a key theme in .gtkrc-2.0. Is there one in 1.x? Yes, people on IRC saw this setting in 1.2 as well. > This might only be feasible in gtk2 mozilla builds. We'll have a pref as well. I would implement this via nsILookAndFeel:GetMetric(). The widget/src/base/nsXPLookAndFeel.cpp file always checks a pref as a fallback override mechanism for setting metrics. That's checked first to see if the override pref is used. If it's not, the indivual widget/src/[platform]/nsLookAndFeel.cpp on each platform uses an OS mechanism to set the metric. So, we need to hack wherever in Mozilla we define the location of the subdirectory for the currently used platformHTMLBindings.xml. It probably will not be that easy if only one copy of platformHTMLBindings.xml is JAR'd up. We'd have to ship both. > Checking the gtk2 pref and not a kde pref is probably reasonable given that > mozilla has always been a gtk app (if we ever get a qt build, then that can be > revisited). Agreed, we use the gtk settings in other places. > Is "Emacs" the only gtk key theme which implements these bindings? Don't know, but we should have a pref > Of course, people who > use custom themes and don't name them "Emacs" will have no recourse They will through the pref. > Be aware of bugs 164638 and 89524 (which I think are dups of each other?). It > may or may not be possible to change XBL key bindings after startup (those bugs apply to the accel key pref, not to the bindings themselves). Hmm, that actually might make the pref impractical since the pref is loaded after the profile manager. I'm not sure -- anyway we can still use the gtk pref at least on Unix/Linux. As long as we hack the code to use the right platformHTMLBindings.xml I think we're probably okay. I could definitely use help on this, otherwise people will have to wait a while. I just want to get an agreeable plan in place.
> Proposal: > 1. If Mozilla is running on top of Gnome (if we can detect that), follow the > Gnome emacs key binding pref that's already in Gnome. > 2. Otherwise, keep the same behavior we have now. Hmm, I run Gnome from time to time, but have no idea what "the Gnome emacs key binding" is. You can run Gnome, and a lot of applications that aren't Gnome, thus never see the Gnome key bindings. Therefore, I think a pref in Mozilla should not be clever like this. It should be the same behaviour regardless of what kind of desktop the user happens to be running. There should at least be a choice 3: 3. Use Emacs keybindings, period.
(In reply to comment #37) > You can run Gnome, and a lot of applications that aren't Gnome, > thus never see the Gnome key bindings. So your argument is: because other apps don't try to fit into the environment they run on, why should Mozilla? In that case, why do we try to fit into the environment at all? We can totally ignore the native system settings and appearance. :) > It should be the same behaviour regardless of > what kind of desktop the user happens to be running. You want emacs key bindings on Mac OS X and Windows? You want function keys for operations on the Mac? You want Alt+F to bring up the File menu on a Mac? Maybe we should have a universal file open dialog and ignore the native one. > There should at least be a choice 3: > 3. Use Emacs keybindings, period. No thanks -- that will mess the keyboard users on Windows and Mac too now.
Gnome: I thought about mentioning in my previous comment that whether gnome is running is completely irrelevant. I don't run gnome, but I run lots of gtk2 apps which read ~/.gtk-2.0 and my gtk2 key theme. On gtk1: It may be that gtk1 had keythemes, but they definitely weren't necessary to have the readline/emacs key bindings, so most users who expect those bindings won't specify them in a .gtkrc for gtk1. Most users who care about the bindings probably have them specified in .gtk-2.0 by now; the question is, can we call gtkrc routines which will check for .gtk-2.0 even from a gtk1 mozilla build? Thanks for the info about using nsILookAndFeel and therefore having a pref fallback. That sounds like an excellent approach. However, can I suggest a slight tweak? Is there any chance that the fallback pref could specify a file (either filename to be found in the profile, or a file: url) from which to load the bindings, then not only would that solve this bug, but it would also fix the userHTMLBindings.xbl regression (users used to be able to specify their own key bindings, but can't any more). I haven't looked at the XBL file loading code in a while, so I don't know whether this would be any more difficult. >> 3. Use Emacs keybindings, period. > No thanks -- that will mess the keyboard users on Windows and Mac too now. There's a bug with a reviewed patch which is going to add them to Mac very soon, if it hasn't already gone in. There aren't any conflicts on the mac since the mac uses cmd- for its window-level xul bindings. Native windows apps have always used most of these bindings too, but not that many people on windows seem to care strongly enough to fight to get them included in mozilla to make it act like native apps.
> > You can run Gnome, and a lot of applications that aren't Gnome, > > thus never see the Gnome key bindings. > So your argument is: because other apps don't try to fit into the environment > they run on, why should Mozilla? In that case, why do we try to fit into the > environment at all? We can totally ignore the native system settings and > appearance. :) Applications should not try to fit the environment, they should try to fit the user. My argument is: Users running Gnome may not care much for the Gnome key bindings. > > It should be the same behaviour regardless of > > what kind of desktop the user happens to be running. > You want emacs key bindings on Mac OS X and Windows? You want function keys for > operations on the Mac? You want Alt+F to bring up the File menu on a Mac? Maybe > we should have a universal file open dialog and ignore the native one. Well, I don't do Windows much, but of course I want consistent behaviour in Mozilla across platforms. Note that many Mac OSX applications already has Emacs keybindings. Mozilla does not conform to the environment there. Actually there is a bug about this, 229473. I have nothing against Mozilla trying to implement the most crazy keybindings if it so chooses, but this bug is about getting Emacs keybindings as a preference. Gnome keybindings are not Emacs key bindings. > > There should at least be a choice 3: > > 3. Use Emacs keybindings, period. > No thanks -- that will mess the keyboard users on Windows and Mac too now. Exactly what Mac users want, see 229473. I don't know about Windows users.
*** Bug 254903 has been marked as a duplicate of this bug. ***
*** Bug 256584 has been marked as a duplicate of this bug. ***
Did the patch in bug 257405 fix this?
Well, this is fixed in Firefox 1.0 Preview Release, so it looks like that patch did it, at least for Firefox.
I totally agree that mozilla should have the emacs bindings switch it has under linux on *all* platforms, and that it should replace native bindings. That's what anyone who would switch that preference on wants.
*** Bug 314597 has been marked as a duplicate of this bug. ***
Please consider that on MacOS X Emacs-shortcuts *are* native. All Cocoa-apps support them out of the box and there is no overlap to other shortcuts because OS X uses the Command key for these.
*** Bug 88743 has been marked as a duplicate of this bug. ***
It is embarassing that I have had emacs keybindings for Microsft Word and Outlook for eons, but Firefox and Thunderbird do not. Not only that, but I used to have it working to some extent using the technique outlined here: http://kb.mozillazine.org/Emacs_Keybindings_(Firefox) But due to this bug #201011, it has been broken a very very long time and is no longer possible to "do it yourself". See also: #85799
Comment 39 seems to be about Windows, and has nothing to do with this bug as filed (which was Linux-only). Please don't hijack bugs.
Oops, sorry. Would take it back if I could. I was moving too fast with my attempt to federate the related issues.
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
QA Contact: keyboard.navigation
Component: Keyboard: Navigation → User events and focus handling
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: