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




18 years ago
12 days ago


(Reporter: sujay, Unassigned)


Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [need info])


(2 attachments, 1 obsolete attachment)



18 years ago
Ctrl-K is bringing up spellchecker...it should be deleting to end of line

Ctrl-H is bringing up history window...it 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 ***
Last Resolved: 18 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....

Comment 4

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


18 years ago
Target Milestone: --- → mozilla0.9.1

Comment 6

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

Comment 7

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

Comment 8

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


18 years ago


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

Comment 9

18 years ago
Target Milestone: mozilla0.9.4 → mozilla0.9.5

Comment 10

18 years ago
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)

Comment 11

18 years ago
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. ***


18 years ago
Target Milestone: mozilla0.9.5 → mozilla0.9.6


18 years ago
Blocks: 102993


18 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7


18 years ago
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. ***

Comment 15

17 years ago
-> bryner for investigation (sorry, no linux box)
Assignee: saari → bryner

Comment 16

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

Comment 17

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

Comment 19

17 years ago
*** Bug 125441 has been marked as a duplicate of this bug. ***


17 years ago
Depends on: 127812


17 years ago
No longer depends on: 127812


17 years ago
Blocks: 127812

Comment 20

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

Comment 22

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

Comment 23

17 years ago
nsbeta1- per Nav triage team, ->1.2
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.2

Comment 24

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

Comment 26

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

Comment 27

17 years ago
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)

Comment 28

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

Comment 30

17 years ago
oh,:-(,yes, bz. there is spell-checked in commercial builds.


17 years ago
Attachment #91792 - Attachment is obsolete: true

Comment 31

17 years ago
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?

Comment 32

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

Comment 33

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

Comment 34

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

Comment 35

16 years ago
*** Bug 193095 has been marked as a duplicate of this bug. ***


16 years ago
No longer blocks: 102993

Comment 36

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

Comment 37

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

Comment 38

16 years ago
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".

Comment 39

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

Comment 40

16 years ago
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?


Comment 41

15 years ago
(In reply to comment #0)
> Ctrl-K is bringing up spellchecker...it should be deleting to end of line
> Ctrl-H is bringing up history window...it 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.

Comment 46

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

Comment 48

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

Comment 51

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

Comment 52

14 years ago
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
Product: Core → Core
You need to log in before you can comment on or make changes to this bug.