1862256 - Behavior of home/end and ctrl+a/e in textarea is inconsistent with other browsers

Status: ASSIGNED

(Core :: DOM: Editor, defect, P2)

Description

[Laura Hausmann]

Steps to reproduce:

• Type a long line of text into a textarea field, so that it wraps into the next line
• Press the home key (or ctrl+a)

Actual results:

Caret jumps to start of the wrapped line

Expected results:

Caret jumps to start of line of text

Comment 1

[Laura Hausmann]

I've already submitted a patch for this on Phabricator, but I think even after editing the title it did not get linked to the bug.

Comment 2

[Laura Hausmann]

Attachment: Bug 1862256 - Fix textarea home/end behavior

This patch fixes home/end behavior in textareas. Currently, Firefox' behavior differs from every other major browser in that home/end and ctrl+a/e on macOS jumps to the start/end of the line as it's rendered on screen, respecting line wraps. This is anything but intuitive, as every other application jumps to the start/end of the logical line-of-text instead, ignoring line wraps. An about:config option to restore previous behavior is included.

It sometimes jumps up a line when pressing home/end in an empty line, but this isn't any different from current behavior. I presume the bug lies in GetPrimaryFrameForFocusNode.

I didn't find a bugzilla bug for this, though I imagine I just didn't look hard enough, as this seems like a fairly common complaint, at least from asking my friend circle.

This is my first upstreamed patch, I hope I did everything correctly.

Comment 3

[Kagami Rosylight [:saschanaz] (they/them)]

BTW, we somehow have macOS shortcut definitions in two places:

• https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/dom/events/ShortcutKeyDefinitions.cpp (under MOZ_WIDGET_COCOA)
• https://searchfox.org/mozilla-central/rev/8acfbe4ba09b46b91c862dc2fbc064d4fc1bac9a/widget/cocoa/NativeKeyBindings.mm

Do we need both, or is either one of it a redundant of the other? :masayuki, do you know why we have both?

Comment 4

[Laura Hausmann]

Attachment: Bug 1862256 - Fix textarea home/end behavior r=saschanaz

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)(sickish, maybe slower respose)]

NativeKeyBindings.mm was created later than the XBL shortcut definition which ShoftcutKeyDefinition.cpp based on. When I create NativeKeyBindings, I just stop removing duplicated shortcuts because it's hard to check the default shortcut key definitions of OS X/macOS which were supported. Therefore, the redundant items which you are sure can be deleted.

Comment 6

[Kagami Rosylight [:saschanaz] (they/them)]

Attachment: Bug 1862256 - Part 2: Add test r=masayuki

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ccb29705b1d5
Fix textarea home/end behavior r=saschanaz
https://hg.mozilla.org/integration/autoland/rev/b23e836dc19b
Part 2: Add test r=masayuki

Comment 8

[Serban Stanca [:SerbanS]]

Backed out for causing mochitests failures in test_native_key_bindings_mac.html.

• Backout link
• Push with failures
• Failure Log
• Failure line: TEST-UNEXPECTED-FAIL | widget/tests/test_native_key_bindings_mac.html | editable: Incorrect anchor offset - got +0, expected 73

Comment 9

[Kagami Rosylight [:saschanaz] (they/them)]

Described some problems in patch 1.

Comment 10

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.