Open Bug 77976 Opened 24 years ago Updated 2 years ago

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

Categories

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

x86
Linux
defect

Tracking

()

People

(Reporter: sujay, Unassigned)

References

Details

(Whiteboard: [need info])

Attachments

(2 files, 1 obsolete file)

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 ***
Status: NEW → RESOLVED
Closed: 24 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].
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
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....
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.
Status: REOPENED → ASSIGNED
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
Status: ASSIGNED → NEW
I don't think we should commit to fixing this for beta, but need for release. ->0.9.2/P3
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
Status: NEW → ASSIGNED
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
->0.9.5
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) workaround.
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
Status: ASSIGNED → NEW
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 ones).
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 history) In compose edit area (xul-widget-editor): C-k not work , C-h not work(bring up history)
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 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.
Attached patch make the ctrl-k work in the mail's compose (obsolete) (deleted) — Splinter Review
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" 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?
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 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.
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 bindings? What is the recommended action for users who need key bindings when XUL has eaten them? -wdc
(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.
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.
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
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: