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)
Tracking
()
NEW
People
(Reporter: sujay, Unassigned)
References
Details
(Whiteboard: [need info])
Attachments
(2 files, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
application/vnd.mozilla.xul+xml
|
Details |
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•24 years ago
|
||
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
Comment 2•24 years ago
|
||
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 → ---
Comment 3•24 years ago
|
||
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•24 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.
Updated•24 years ago
|
Status: REOPENED → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Comment 6•24 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
Status: ASSIGNED → NEW
Comment 7•24 years ago
|
||
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
Comment 8•23 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
Updated•23 years ago
|
Status: NEW → ASSIGNED
Updated•23 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
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Comment 10•23 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)
workaround.
Comment 11•23 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.
Comment 12•23 years ago
|
||
*** Bug 96310 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Updated•23 years ago
|
Target Milestone: mozilla0.9.7 → mozilla0.9.9
Comment 13•23 years ago
|
||
*** Bug 112254 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
*** Bug 117445 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
-> bryner for investigation (sorry, no linux box)
Assignee: saari → bryner
Status: ASSIGNED → NEW
Comment 16•23 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•23 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.
Comment 19•23 years ago
|
||
*** Bug 125441 has been marked as a duplicate of this bug. ***
Comment 20•23 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]
Comment 22•23 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
ones).
Comment 23•23 years ago
|
||
nsbeta1- per Nav triage team, ->1.2
Comment 24•23 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
history)
In compose edit area (xul-widget-editor): C-k not work , C-h not work(bring up
history)
Comment 25•22 years ago
|
||
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•22 years ago
|
||
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•22 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•22 years ago
|
||
Could some one review it ?
Comment 29•22 years ago
|
||
> 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•22 years ago
|
||
oh,:-(,yes, bz. there is spell-checked in commercial builds.
Updated•22 years ago
|
Attachment #91792 -
Attachment is obsolete: true
Comment 31•22 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"
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•22 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•22 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•22 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•22 years ago
|
||
*** Bug 193095 has been marked as a duplicate of this bug. ***
Comment 36•22 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•22 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•22 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•22 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
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•21 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
bindings?
What is the recommended action for users who need key bindings when XUL has
eaten them?
-wdc
Comment 41•20 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.
Comment 42•20 years ago
|
||
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•20 years ago
|
||
see bug 257405 (which applies to firefox as well). should this be marked a dup
of 257405?
Comment 44•20 years ago
|
||
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•20 years ago
|
||
Comment 46•20 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?
Thanks.
Comment 47•20 years ago
|
||
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•20 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.
Comment 49•20 years ago
|
||
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•20 years ago
|
||
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•20 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•20 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.
Updated•18 years ago
|
Assignee: bryner → nobody
QA Contact: bugzilla → keyboard.navigation
Target Milestone: mozilla1.2alpha → ---
Assignee | ||
Updated•6 years ago
|
Component: Keyboard: Navigation → User events and focus handling
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•