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

Status: NEW

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

Description

[sujay]

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

Comment 1

[sairuh (rarely reading bugmail)]

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 ***

Comment 2

[sairuh (rarely reading bugmail)]

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].

Comment 3

[Boris Zbarsky [:bzbarsky]]

I'm not sure whether this is relevant to this bug or should be a separate bug,
but...

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

[Akkana Peck]

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.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Bug 78239 filed

Comment 6

[Akkana Peck]

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.

Comment 7

[Peter Trudelle]

I don't think we should commit to fixing this for beta, but need for release. 
->0.9.2/P3

Comment 8

[Peter Trudelle]

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

Comment 9

[saari (gone)]

->0.9.5

Comment 10

[Jason Goodman]

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)
workaround.

Comment 11

[André Dahlqvist]

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.

Comment 12

[Asa Dotzler [:asa]]

*** Bug 96310 has been marked as a duplicate of this bug. ***

Comment 13

[Boris Zbarsky [:bzbarsky]]

*** Bug 112254 has been marked as a duplicate of this bug. ***

Comment 14

[Boris Zbarsky [:bzbarsky]]

*** Bug 117445 has been marked as a duplicate of this bug. ***

Comment 15

[saari (gone)]

-> bryner for investigation (sorry, no linux box)

Comment 16

[John Morrison]

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

[Akkana Peck]

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.

Comment 18

[Brian Ryner (not reading)]

Nominating for nsbeta1 triage.

Comment 19

[Akkana Peck]

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

Comment 20

[Peter Trudelle]

ADT triage team needs info: Is this really Linux-specific?  Does it affect
anything other than Emacs or user-specified key bindings?

Comment 21

[Brian Ryner (not reading)]

not going to make 0.9.9

Comment 22

[Akkana Peck]

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
ones).

Comment 23

[Peter Trudelle]

nsbeta1- per Nav triage team, ->1.2

Comment 24

[Gilbert Fang]

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
history)
In compose edit area (xul-widget-editor): C-k not work , C-h not work(bring up
history)

Comment 25

[Crutcher Dunnavant]

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

[Gilbert Fang]

By now, in my latest trunk building on solaris, ctrl-H and Ctrl-k works almost
well. 
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

[Gilbert Fang]

Attachment: make the ctrl-k work in the 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)

Comment 28

[Gilbert Fang]

Could some one review it ?

Comment 29

[Boris Zbarsky [:bzbarsky]]

> 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

[Gilbert Fang]

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

Comment 31

[Gilbert Fang]

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"
accesskey="&editcheckspelling.accesskey;"
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

[Akkana Peck]

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

[Dom Layfield]

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

[Dom Layfield]

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

[R.K.Aa.]

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

Comment 36

[greggyb]

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

[greggyb]

Attachment: remap keys to alt-* to avoid conflicting with emacs keybindings

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

[greggyb]

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

[William Cattey]

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
Akkana).

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

[William Cattey]

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
bindings?

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

-wdc

Comment 41

[Lee Revell]

(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. 

Comment 42

[[e-mail]]

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.

Comment 43

[sairuh (rarely reading bugmail)]

see bug 257405 (which applies to firefox as well). should this be marked a dup
of 257405?

Comment 44

[Boris Zbarsky [:bzbarsky]]

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 45

[Keith Hanlan]

Attachment: userHTMLBindings.xml to map control-k to cmd_deleteToEndOfLine

Comment 46

[Keith Hanlan]

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?
Thanks.

Comment 47

[Boris Zbarsky [:bzbarsky]]

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

[Keith Hanlan]

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.

Comment 49

[Boris Zbarsky [:bzbarsky]]

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.

Comment 50

[Mathieu Pillard [:mat]]

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

[Keith Hanlan]

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

[Keith Hanlan]

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.