Open Bug 77976 Opened 20 years ago Updated 2 years ago

[Linux/UNIX] Ctrl-H and Ctrl-K not doing what they're supposed to do


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





(Reporter: sujay, Unassigned)



(Whiteboard: [need info])


(2 files, 1 obsolete file)

Ctrl-K is bringing up should be deleting to end of line

Ctrl-H is bringing up history should be deleting backward
seems like this would be a dup of bug 71779. [see also bug 77742 which i had
filed for Control+A, similar issue which was dup'd in favor of 71779.]

*** This bug has been marked as a duplicate of 71779 ***
Closed: 20 years ago
Resolution: --- → DUPLICATE
chatted w/akkana --i'm sorry, i misunderstood this bug, so reopening.

this is what i see in composer using a commercial verification build on linux
[2001.04.27.05] --note, my accel key is control:

* control+H brings up the History window.
* control+K brings up the Spell Checker.

this is what i see in composer using a linux debug mozilla build from last night
[21:08 pull, 4/26]:

* control+H brings up the History window.
* control+K deletes to end of line [expected].
Resolution: DUPLICATE → ---
I'm not sure whether this is relevant to this bug or should be a separate bug,

C-k should delete to end of line if there is something on the line.  If the only
thing on the line is a linefeed, C-k should delete the line itself.

So "aa\nbb\ncc" becomes "aa\ncc" after C-k is hit twice at the beginning of
"bb".  Currently, the second C-k just does nothing....
Boris: that should be a separate bug.  It worked once, but regressed quite a
while ago, and I've been too lazy to file it or fix it since no one else was
complaining.  Please file a new bug, to me, component editor, and I'll look into it.
Target Milestone: --- → mozilla0.9.1
The offending bindings are coming from XUL, and are overriding the XBL bindings.
Talked with saari, and we both agree that it should work the other way: XBL
bindings for the editor (at least when the content area is focused, which is
basically always) should override XUL, not the other way around.  Saari thinks
perhaps the key binding system isn't checking for the focused element.

We should try to keep this in the 0.9.1 milestone, since things aren't working
the way they're supposed to.

I'll try to help out with this as much as I can before my sabbatical.
Assignee: akkana → saari
I don't think we should commit to fixing this for beta, but need for release. 
Priority: -- → P3
Target Milestone: mozilla0.9.1 → mozilla0.9.2
No longer fits the profile for work we can do for 0.9.2, but could still make it
in via "limbo" after we get shippable bits. ->0.9.3
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Summary: Ctrl-H and Ctrl-K not doing what they're supposed to do → [Linux/UNIX] Ctrl-H and Ctrl-K not doing what they're supposed to do
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
See bug 96310 for a related / duplicate(?) problem, and a work-around.

Quick summary: ctrl-f, ctrl-b, ctrl-n, and ctrl-p (Emacs cursor-movement keys)
are also incorrectly treated as menu-item accelerators in the mail compose
window.  Akkana posts that changing the accelerator key from Ctrl to Alt
eliminates the conflict.

This bug annoyed me to no end until Akkana posted the (far-too-arcane)
Has this been fixed, or have I been smoking something? Ctrl-K deletes to the end
of the line when I tried it in this "Additional Comments:" textfield and
"Ctrl-H" deletes backwards. The other normal emacs navigation keys work too, but
I have not tried them in mail.
*** Bug 96310 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Blocks: 102993
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.9
*** Bug 112254 has been marked as a duplicate of this bug. ***
*** Bug 117445 has been marked as a duplicate of this bug. ***
-> bryner for investigation (sorry, no linux box)
Assignee: saari → bryner
ctrl-{a,e,b,f,k,w,d} all perform their emacs defuns in a single line textfield
in the urlbar, in a 'To:' field of msgcompose, in the subjectline of 
msgcompose, and in a <input type=text> in an HTML form with either todays 
commercial or mozilla builds.

ctrl-{p,n} in a single line textfield do 'Print' and 'New Navigator Window', 
although it's hard to argue that they should do next-line/previous-line with
only a single line available.

In a msgcompose composition area, or in Composer composition area, many of 
these bindings do not have their emacs meanings (when used with ctrl). But 
I don't know if it is a goal to make that work.
The intent is that the XBL (editing) bindings take precedence over the XUL
bindings (and they used to, until this regression) ...  in addition to wanting
editing to work, XUL taking precedence over XBL also makes it impossible for the
user to customize bindings, since XUL bindings aren't customizable (without
exploding the jar files) so the user has no way to override or disable them.
Nominating for nsbeta1 triage.
Keywords: nsbeta1
*** Bug 125441 has been marked as a duplicate of this bug. ***
Depends on: atfmeta
No longer depends on: atfmeta
Blocks: atfmeta
ADT triage team needs info: Is this really Linux-specific?  Does it affect
anything other than Emacs or user-specified key bindings?
Whiteboard: [need info]
not going to make 0.9.9
Target Milestone: mozilla0.9.9 → mozilla1.0
Yes, it's Unix specific.  It affects all the standard editing and motion
keybindings that Unix users expect to have working in editable content (as well
as making it impossible to set up user specified key bindings that override XUL
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2
I investigated this bug on my soalris.
The result is :
In toolbar's urlbar ( it is actually a xul:html:input), C-k work, C-h work.
In a textarea form of a html page: C-k  work, C-h work.
In a input form   of  a html page: C-k work , C-h  work
In composer's edit area ( xul-widget-editor): C-k work, C-h not work(bring up
In compose edit area (xul-widget-editor): C-k not work , C-h not work(bring up

Ctrl-W, which kills words in textareas (as it should), kills windows else where.
But in the editor and in the message composer, it kills the window, which is
incorrect behaviour.
By now, in my latest trunk building on solaris, ctrl-H and Ctrl-k works almost
xul-widget: in toolbar's urlbar ( it is actually a xul:html:input), C-k work,
C-h work.
text area in html : In a textarea form of a html page: C-k  work, C-h work.
input field : In a input form   of  a html page: C-k work , C-h  work
composer: In composer's edit area ( xul-widget-editor): C-k work, C-h work 
mails's  compose: edit area (xul-widget-editor): C-h  work , C-k  not work(no
action at all). 
If we do not consider the conflicts of the keybindings,(which should be at bug
102993),  this bug only need a very simple patch to fix the wrong action in
mail's compose. 
by now, there is actually no cmd_spelling for the compose, and this event
handler prevent the latter hander works(to kill the words to the end)
Could some one review it ?
> by now, there is actually no cmd_spelling for the compose

There isn't?  There certainly is in commerical builds, and if a spell-checker
lands for Mozilla (eg the one at mozdev) then there will be in Mozilla too.
oh,:-(,yes, bz. there is spell-checked in commercial builds.
Attachment #91792 - Attachment is obsolete: true
But I find in composer, it seems spell-checker is disabled 
mozilla/ editor/ ui/ composer/ content/ editorOverlay.xul 
 58     <key id="checkspellingkb"   key="&editcheckspelling.keybinding;"  
observes="cmd_spelling"  modifiers="accel" disabled="true"/>

364       <menuitem id="menu_checkspelling"
365                 key="checkspellingkb"   observes="cmd_spelling" disabled="true"
366                 label="&checkSpellingCmd.label;"/>

So how about we make it disabled in mail's compose too?
There are other keys that should work but don't: for example, ctrl-n and ctrl-p
(next and previous line).  So this is still an issue even aside from not wanting
to disable spell checking.
C-k still flakey in Linux 1.1b build.

Works in Browser URL box, but not in Compose new mail.  Seems bizarre, since
most of the other EMACS keystrokes work nicely (C-e, C-a, C-h).

Is there some (easily-modifiable) configuration file where these binding are
set?  Can't find info in documentation.
Oooops!  Sorry about that.  I'd installed new version of Moz, but not noticed
that  I was actually still running the old version.

CTRL-K works beautifully in current Linux build.  Thanks!
*** Bug 193095 has been marked as a duplicate of this bug. ***
No longer blocks: 102993
Just wondering if anyone is actively working on this bug.  I tried to track down
the parts of the code related to this, but I didn't get very far.

I managed to edit two xul files enough to get things to work close to the way I
want, though.  I believe ctrl-{a,d,e,h} work in 1.3.  I got ctrl-{n,p,b,f} to
work by re-mapping the print function to alt-a, the bold function to alt-b, and
the find function to alt-f (within a composer window).  I just turned off the
New Navigator function within the composer window, because I was unsuccessful in
changing it to alt-n (and because I never use it from within the composer).  I
was unable to get ctrl-w (delete previous word) to work.  In case you're
wondering, yes, I know about the ui.key.accelKey pref, but I didn't want to
change my accel key globally.

Ideally, these changes would only take effect in unix, but I'm not that clever,
so I'm not suggesting my changes as a patch.  If anyone with a more intimate
knowledge of xul wants to try something like that, I think that would please
most of the people bothered by this bug.

I'm not sure what the rules are for posting a patch: since I don't expect my
changes to make it in to the codebase, I'm not posting them, but if it would be
helpful, and someone wants the patch, let me know.

If the preferable solution described in comment #6 involves only a modest amount
of code (or programmer time) and someone can point me in the right direction,
I'll try to fix it that way, but I'm too unfamiliar with the code to try to
track down all the relevant bits myself.
This is not the right way to fix this bug, but it makes me happy in the
meantime, and hopefully it will be useful to someone else as well.  ctrl-n,
ctrl-p, ctrl-b, ctrl-f, and ctrl-k all work as expected.  The keys for new
navigator, print, bold, find, and spellcheck are rebound to alt-* to avoid
conflicting with the emacs bindings.
I believe ctrl-h actually works in the default version, and ctrl-k may as well
(since spellchecking is still disabled by default, I think), so the summary for
this bug is not very accurate.  The bug should be probably be renamed to
something more descriptive of the real problem, e.g. "various emacs keybindings
unavailable in mail compose" or "xul overrides xbl in some cases, breaking emacs
keybindings for mail compose".
The original bug I opened, which was deemed as a duplicate of this bug,
had NOTHING to do with emacs bindings.

I'd gotten used to typing ^o to open a URL instead of ^L.  When I went to
try and change that binding, it proved impossible.  The root cause was that
XUL bindings were not able to be overridden once set. (See comments 6 and 17 by

Correct me if I'm wrong, but I believe the root problem is STILL unaddressed:
Hard-coded bindings from XUL cannot be overridden by XBL once set.

I was told that this required re-architecting how all key binding was done.

I am writing this comment to put this bug BACK into perspective so that we don't
lose the reason why it was opened in the first place.
Blocks: 110517
Someone contacted me today asking me if my bug was ever resolved.

Perhaps if I add this comment it will cause the bug to re-register on someone's
radar screen?

QUESTION:  Is it still impossible for user-defined key bindings to override XUL

What is the recommended action for users who need key bindings when XUL has
eaten them?

(In reply to comment #0)
> Ctrl-K is bringing up should be deleting to end of line
> Ctrl-H is bringing up history should be deleting backward

All I want to know is, how do I access History from the location bar?  The above
comments indicate that Alt-H should work, but it doesn't.  At the very least, if
alt-H is fixed, please change the shortcut in the Go menu to match. 
Does this bug apply to Firefox too or should there be a seperate bug?
Because in FF 1.0PR, Ctrl-K will jump to the next entry field instead of
deleting to end of line.
see bug 257405 (which applies to firefox as well). should this be marked a dup
of 257405?
Wasn't this bug about XUL overriding XBL bindings?  That would override the
native bindings added in bug 257405 too.  So no, this is not a duplicate.
Something has changed between 1.7.3 and 1.7.6 that causes this problem to arise.
I tried creating a userHTMLBindings.xml file (see attachment) to forcibly map
control-k to cmd_deleteToEndOfLine but it has no effect.

Another effect is that control-a now highlights the text instead of going to the
beginning of the line. All-in-all, a rather annoying development. Is there a
work-around that I can use or do I need to go back to an earlier release?
Keith, did you switch from a GTK1 build to a GTK2 one?  If so, you're picking up
the GTK2 key preferences now; you can adjust them in your GTK2 configuration.
Boris, your supposition is 100% correct. Yes, I built 1.7.6 with GTK2. However,
I'm not sure how to go about changing my GTK options as you suggest. Are these
global options or mozilla gtk build options to which you are referring? Thanks
very much for your quick response.
They're global GTK options.  I don't use GTK2 or GNOME myself, so I don't know
where one would change them; I think I recall being told it's in the GNOME
config panels somewhere.
IIRC there was an option in a gnome panel but it got removed.
If you are using gnome, use gconf-editor and change
/desktop/gnome/interface/gtk_key_theme to "Emacs".

If you are not, then edit yout ~/.gtkrc-2.0 and add:
include "/usr/share/themes/Emacs/gtk-2.0-key/gtkrc"
gtk-key-theme-name = "Emacs"

(You might need to change that include line)

I'm using this "Emacs" key theme and all emacs-like keybinding that I expected
to work in gecko do work (ctrl-a, ctrl-k, etc)
Boris, I used gnome-keybinding-properties to change the "Text editing shortcuts"
from "Gnome Default" to "Emacs" and it fixed my problem. Thank you very much.
Just a quick correction now that I understand the issue a bit better. My
previous comment seems to be incorrect as the incorrect key behaviour resumed
after I killed my X session and logged back in. My changes via
gnome-keybinding-properties were still intact but the behaviour in Mozilla
reverted to non-Emacs keybindings.

I realize now that since I am running on a RedHat 9.0-based system, I am using
gnome-1.2. I built Mozilla using gtk2 and therefore need to make my
configuration changes visable to those libraries. Mat's suggestion worked
perfectly: I didn't have a ~/.gtkrc-2.0 configuration file but when I created
one with the two lines he specifies, my problem cleared.

Thank you Mat for your precise and accurate instructions. They worked.
Assignee: bryner → nobody
QA Contact: bugzilla → keyboard.navigation
Target Milestone: mozilla1.2alpha → ---
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.