Closed Bug 418226 Opened 16 years ago Closed 16 years ago

Some emacs style keybindings (CTRL+A, CTRL+E, CTRL+K) are now broken as of Beta 3

Categories

(Core :: Widget: Cocoa, defect, P1)

PowerPC
macOS
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: eightbithero, Assigned: jaas)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021704 Minefield/3.0b4pre
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b4pre) Gecko/2008021704 Minefield/3.0b4pre

In Firefox 2.0 and, if I remember correctly, Firefox 3.0b2, I could use emacs style keybindings to navigate input boxes and text areas – CTRL+A to go to the beginning of a line, CTRL+E to go to the end, CTRL+K to kill a line. The new betas, up through b4, have broken that.

Reproducible: Always

Steps to Reproduce:
1. Click on a text box
2. Hit CTRL+A
3. Nothing happens.
Actual Results:  
Nothing. That's the problem.

Expected Results:  
The caret goes to the beginning of the line.

I'd say this is actually a minor bug, but since it's been destroying my carefully honed habits, and I really want it fixed before the RCs, I'm leaving the severity as normal.
I wrote something similar in https://bugzilla.mozilla.org/show_bug.cgi?id=282097#c9
I thought bug 282097 was the bug for this but is it different issue?
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
If they used to work in 2.0 and especially in 3.0b<3, it's not bug 282097, but a separate regression, and this bug should be re-opened.

(Bug 282097 is about the fact that certain keystrokes are hard-coded to work, but that others (and additional user-generated bindings) don't work at all.)
Attached file testcase
Use this testcase for testing, since many other easily-accessible <textarea>s are on pages with access keys defined that conflict with the emacs bindings.
Yeah, this is a "recent" regression.

I don't have a lot of trunk builds around ATM, but this works in CmTrunk 2008-01-21 00:00 and doesn't work in a build from today.
Status: RESOLVED → UNCONFIRMED
Component: Keyboard Navigation → Widget: Cocoa
Keywords: regression, testcase
Product: Firefox → Core
Resolution: DUPLICATE → ---
Assignee: nobody → joshmoz
Status: UNCONFIRMED → NEW
Ever confirmed: true
QA Contact: keyboard.navigation → cocoa
CmTrunk 2008-02-10-01 works, 2008-02-11-00 fails

Regression range: 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=Camino&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2008-02-10+01%3A00&maxdate=2008-02-11+00%3A00&cvsroot=%2Fcvsroot

Nothing in there looking widget-suspicious; the most "promising" one seems to be bug 415860.  

Smaug, could that patch have caused these emacs bindings (defined in content/xbl/builtin/mac/platformHTMLBindings.xml) to have stopped working?

Just to be clear, here were my STR:

1. Open testcase (or http://www.google.com)
2. Type some text
3. Ctrl-a to move to the left edge of the textarea/field
4. Ctrl-k to kill all the text

(When 3 failed, I manually moved the cursor, just to ensure 4 also started failing at the same time.)

At any rate, probably not a Cocoa Widget bug, so please move when we decide where it really belongs.
Flags: blocking1.9?
> Smaug, could that patch have caused these emacs bindings (defined in
> content/xbl/builtin/mac/platformHTMLBindings.xml) to have stopped working?

Possible, but can't test because Ctrl-a/Ctrl-k have different meaning in 
Linux.
Would be very unfortunate to have a regression for bug 415860, which itself
is a regression :(
I'll look at this some more tomorrow.
Oh, sorry, Smaug; this is almost certainly the backout of bug 358379 (aka the fix for bug 415923); I confused those with the backout of bug 400028 when I was reading bonsai.

I'm not sure the right way to do the blocks business when a regression is due to the backout of a bug, but the new fix for bug 358379 needs to make sure it fixes this, so I guess the blocks goes to it?
Blocks: 358379
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1
This bug is not present in beta 3 when running on Tiger. Ctrl+a moves to start of line, ctrl+e end of line, and ctrl+k kills from the caret to the end of line (not sure if that's how it worked in Fx2, but it's consistent with other Cocoa apps). Ctrl+u kills the entire line.
fixed by patch on bug 358379
Status: NEW → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
The command + delete still doesn't work but is this another bug?
I filed Bug 420669 for the bug in comment 12
Is there a bug for ctrl+y not pasting texts killed by ctrl+k?
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: