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?

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

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.

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.

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

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

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?