Closed Bug 893670 Opened 12 years ago Closed 12 years ago

Emacs like goto beginning/end of line shortcuts stopped working inside <textarea>s

Categories

(Core :: Widget: Cocoa, defect)

All
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla25

People

(Reporter: reuben, Assigned: jryans)

References

Details

(Keywords: regression)

Attachments

(2 files, 1 obsolete file)

STR: 1) data:text/html,<body onload="t.focus()"><textarea id="t">foobar</textarea></body> 2) Try to use control+E, control+A to move the caret to the end of line. Expected results: Caret is moved accordingly. Actual results: Caret is not moved.
Initial range on central: dde4dcd6fa46 2013-07-11 GOOD b44898282f21 2013-07-12 FAIL https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=dde4dcd6fa46&tochange=b44898282f21
This might be fallout from the patch for bug 282097.
Yes, sounds likely. I'll take a look.
Assignee: nobody → jryans
Status: NEW → ASSIGNED
I've removed most of the conditionals that were added to only allow paragraph selectors to work on text inputs. This is a little confusing, since for editable elements and textareas, these are line motions, even though the selector says paragraph. The default OS X bindings for these Emacs-style commands (ctrl+a, ctrl+e, etc.) use paragraph selectors, so this change at least restores those keystrokes to the line motions that they made prior to bug #282097 landing.
Attachment #777543 - Flags: review?(masayuki)
I've greatly expanded the test for NativeKeyBindings in several ways: * textareas and inputs are now tested, in addition to the editable element from before * All OS X supported Emacs-style shortcuts are tested
Attachment #777544 - Flags: review?(masayuki)
Comment on attachment 777543 [details] [diff] [review] Part 1: Restore Emacs shortcuts in textareas nice!
Attachment #777543 - Flags: review?(masayuki) → review+
Comment on attachment 777544 [details] [diff] [review] Part 2: Expand NativeKeyBindings tests I'm +'ing this patch. However, you send wrong character when Ctrl key is pressed. For example, if Ctrl + 'a' is pressed, the char should be U+0001 and the unmodified char should be 'a'. http://mxr.mozilla.org/mozilla-central/source/widget/tests/test_keycodes.xul#370 Would you add new patch for fixing this bug? You can research the actual character with TextInputHandler's log. > export NSPR_LOG_FILE=<file name> && export NSPR_LOG_MODULES=TextInputHandlerWidgets:1 Then, the native key event is recorded by this: http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/TextInputHandler.mm#1420
Attachment #777544 - Flags: review?(masayuki) → review+
I mean that you should fix the bug in current test too.
* Corrected characters sent when using modifiers as suggested in comment #7. * Removed page down step because the positioning result was unreliable on try. Carrying over masayuki's r+ from attachment #777544 [details] [diff] [review].
Attachment #777544 - Attachment is obsolete: true
Attachment #778042 - Flags: review+
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: