1539376 - Can't use Fn + Left/Right Arrow key to simulate HOME/END key when typing address or keyword search on Mac

Status: NEW

(Core :: DOM: Editor, enhancement, P5)

Description

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Can't use Fn + Left/Right Arrow key to simulate HOME/END key when typing address or keyword search on Mac.

It's annoying when I try to modify a long URL.

Comment 1

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

Chrome and Brave can deal with this properly.

Comment 2

[Mark Banner (:standard8)]

I just checked, this isn't just the address bar, this is pretty much anything within the browser. Google Docs does handle it, but I suspect that's how their site is set up.

Interestingly, Safari doesn't handle this.

Firefox does handle control-A and control-W which other apps do seem to handle consistently.

Comment 3

[Makoto Kato [:m_kato]]

Safari doesn't move caret by this key operation, but Chrome does. So current key binding is correct as Safari's way.

Stephen and Masayuki, do we add VK_HOME/VK_END key bind for editor like Chrome? How do you think?

Comment 4

[Stephen A Pohl [:spohl]]

I will let Masayuki answer this one.

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Difficult to say...

When I press Fn+ArrowLeft, scrollToBeginningOfDocument: command is fired from OS. On the other hand, Control+a causes moveToBeginningOfParagraph: command.

And also testing with search field in Finder, our behavior conforms to the behavior of native widget.

So, strictly speaking, I don't think we should change our behavior.

On the other hand, as a non-macOS user, it seems odd and inconvenient key mapping. Therefore, it might be better to have a option for mapping to moveToBeginningOfParagraph: and moveToEndOfPargraph: when scrollToBeginningOfDocument or scrollToEndOfDocument.
https://searchfox.org/mozilla-central/rev/ddd1679c0534f7ddf36cafddd17b710c4fefe3c4/widget/cocoa/NativeKeyBindings.mm#160-161

However, I think that we shouldn't change the behavior in scrollable <textrea>. Chrome's behavior is really tricky. When Fn+ArrowLeft or Fn+ArrowRight can scroll, it does not move caret and just scroll. Otherwise, if it's not scrollable (including already scrolled to top- or bottom-most), it moves caret in the line. If we emulate this behavior, we need to hack CommandScrollTop and CommandScrollBottom handlers. Although I'm not sure where there are.

Anyway, strictly speaking, users should customize ~/Library/KeyBindings/DefaultKeyBinding.dict as:

{
  "\UF729" = ("scrollToBeginningOfDocument:", "moveToBeginningOfParagraph:");
  "\UF72B" = ("scrollToEndOfDocument:", "moveToEndOfParagraph:");
}

So, I mean that if a lot of users require this behavior, I think we should take it. Otherwise, we shouldn't.

Comment 6

[Clément Lefèvre]

Interestingly, a full-size external keyboard also fail to move to beginning and end of the URL bar with the physical dedicated home and end keys.
Worth mentioning also: in a textarea, instead of moving the cursor, it's moving the view of the textaria (like scrolling it) without moving the cursor at all.

Comment 8

[Brecht Machie]

Fn+LeftArrow/RightArrow on my MacBook keyboard and Home/End on my USB keyboard do move the cursor to the start/end of the URL bar and search bar. I may have changed my ~/Library/KeyBindings/DefaultKeyBinding.dict since I remember I had issues with these keys before. These are its contents:

{
    /* home */
    "\UF729"  = "moveToBeginningOfLine:";
    "$\UF729" = "moveToBeginningOfLineAndModifySelection:";

    /* end */
    "\UF72B"  = "moveToEndOfLine:";
    "$\UF72B" = "moveToEndOfLineAndModifySelection:";

    /* page up/down */
    "\UF72C"  = "pageUp:";
    "\UF72D"  = "pageDown:";
}

The keys don't work properly in a contenteditable in a shadow root, however. See bug 1623583.