Closed Bug 54399 Opened 25 years ago Closed 24 years ago

Pressing CTRL+K doesnt do anything in windows

Categories

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

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
All
Windows 98
Type:
defect

Tracking

()

Status:
VERIFIED WONTFIX

People

(Reporter: vladimire, Assigned: mcafee)

Details

BUILD: 2000-09-26-08-M18 STEPS TO REPRODUCE: Press CTRL+K. EXPECTED RESULTS: Should delete the end of the current line if you are in a text field. ACTUAL RESULTS: Increases global font size.
I see this too. I haven't yet figured out why it's happening.
This is jag's. He was using modifier+K/modifier+J for Increase/Reduce text size until modifier++/modifier+- was working properly. These items now properly use + and - in the trunk, but the fix didn't go into the branch. Will need to convince PDT to ++ if this is going to be allowed in (to the branch)...
Assignee: don → disttsc
d'oh, collision moment. occurs on linux too (unable to test on mac due to bug 39117). addendum: View > Text Size doesn't appear in the branch bits, only in the trunk bits (even tho' the ctrl+K/J shortcuts work in the branch).
Keywords: rtm
Hardware: PC → All
The short of it is, the text size menu is actually on the trunk, just hidden away. The branch needs to be synchronized with the trunk in this. Patches are attached to bug 53207 (re-enable text size menu) and bug 51597 (change to accel+- and accel++).
Does this still happen? The patches to bug 51597 are on both the tree and the trunk now.
CNTRL+K doesnt increase font size any more, it doesnt do anything... Shouldnt it cut off the end of the word, or line if you are in a text field? or is that a linux only thing?
Vladimire: Are you seeing this (the ctrl-K in text controls not working any more) on the trunk, or on the branch?
using today's branch bits [2000.10.09.09-n6] on linux and winNT, ctrl+k [and ctrl+j] no longer increase [or, decrease] the text size. jag, could this now be marked resolved fixed?
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking fixed. Vladimire, I don't think ctrl-k deletes till the end of line on Windows.
Cntrl+k wasnt working on the branch. build 2000-10-09-08-MN6... Shouldn't Netscape 6 have the same short cuts on all platforms, especially when there is no other platform based shortcut for this key combination. I am reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Removing rtm keyword, changing summary.
Keywords: rtm
Summary: Pressing CTRL+K increases font size in windows. → Pressing CTRL+K doesnt do anything in windows
Thank you for changing the summary to be more clear. Indeed, this isn't "fixed" yet. Reassigning to default module owner. please talk to jglick about this accel key, it is not mentioned in the spec.
Assignee: disttsc → don
Status: REOPENED → NEW
It's a standard Unix editing key binding, which conflicts with Netscape's bindings on Windows (also on Unix, if we persist in using Windows bindings -- that's why we never did in the past). UE didn't even want ^H for backspace, which is standard on both Windows and Mac, much less the other Unix bindings. You can (unless this has regressed) set up custom bindings for text fields and text areas if you personally want the Unix bindings on other platforms, though unfortunately it doesn't seem to work for the editor and mail compose (at least, I haven't figured out how).
Since Don has left, Vishy is taking his bugs in bulk, pending reassignment. thanks, Vishy
Assignee: don → vishy
nsbeta1
Assignee: vishy → mcafee
Keywords: nsbeta1
I think this is a won't fix, please convince me to reopen if needed.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → WONTFIX
it's about emacs bindings or something silly. If anyone intends to reopen it please move to PC/Linux.
Verifying
Status: RESOLVED → VERIFIED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.