Cmd [arrow] commands do not function as expected

[markjaquith]

Issue Overview

In macOS, ⌘ [arrow] commands have well-defined meanings, in a text-editing context.

• ⌘ ↑ takes your caret to the beginning of your content (top-left in LTR languages).
• ⌘ ↓ takes your caret to the end of your content (bottom-right in LTR languages).
• ⌘ ← takes your caret to the beginning of the current line.
• ⌘ → takes your caret to the end of the current line.

In Gutenberg, these commands inconsistently navigate your caret between blocks.

• ⌘ ↑ takes your caret to the same x-value in the previous block.
• ⌘ ↑ in the first block takes your caret to the end of the title.
• ⌘ ↓ takes your caret to the same x-value in the next block.
• ⌘ → in the first block takes your caret to the start of the next block.
• ⌘ → in a middle block takes your caret to the end of that same block (this is correct!)
• ⌘ → in an ending block takes your caret to the start of a new block.
• ⌘ ← takes your caret to the end of the previous block.

Expected Behavior

macOS default behavior.

[afercia]

Question:

• ⌘ ↑ takes your caret to the beginning of your content (top-left in LTR languages).
• ⌘ ↓ takes your caret to the end of your content (bottom-right in LTR languages).

Should a single block (e.g. a paragraph) define an arrow-behavior context? Currently, a single paragraph in Gutenberg is equivalent to a textarea and communicated as such to assistive technologies. Thus, I'd expect arrow commands to work within a single block.

Or, should the whole post be the context for the arrows commands?

[afercia]

Also, worth considering the equivalent arrow commands on Windows.

[mtias]

@mcsf I believe many of these work a lot better now, can you check on the status and see if anything remains to be improved and how pressing it is?

[mcsf]

Somewhat related: #4004

can you check on the status and see if anything remains to be improved and how pressing it is?

I don't think this was ever explicitly implemented in WritingFlow, so what we're seeing ends up being a combination of native behaviour (e.g. jumping to the start or end of a block's text field) with editor behaviour (navigating between blocks when the caret sits at a block boundary).

It could be implemented, but this would be a new task, not a fix.

[mtias]

I've noticed a lot of these interactions being better (moving to the end / beginning of the block, etc), hence the question. It'd be nice to validate a few more and look at implementing missing ones if it can be done reliably across browsers.

[designsimply]

I tested using the demo post with WordPress 4.9.8 and Gutenberg 4.3 using Firefox 63.0.1, Chrome 70.0.3538.77, and Safari 12.0 on macOS 10.13.6 and found the following to be generally true.

When the caret is not at a block boundary:

• ⌘ ↑ takes your caret to the beginning of the current block.
• ⌘ ↓ takes your caret to the end of the current block.
• ⌘ ← takes your caret to the beginning of the current line.
• ⌘ → takes your caret to the end of the current line.

If the caret is sitting at a block boundary:

• ⌘ ↑ takes your caret to the same x-value in the previous block.
• ⌘ ↓ takes your caret to the same x-value in the next block.
• ⌘ ← takes your caret to end of the previous block.
• ⌘ → takes your caret to the beginning of the next block.

Assuming block boundaries are defined as:

• Anywhere on the first line for ⌘ ↑.
• Anywhere on the last line for ⌘ ↓.
• The very first position in the block for ⌘ ←.
• The very last position in the block for ⌘ →.

Exceptions:

• Block boundary movements do not apply to the title (this makes sense as it is not yet a block).
• ⌘ ← and ⌘ → do not work to exit block boundaries in Firefox.
• ⌘ ↑ and ⌘ ← do not work to access empty captions.
• ⌘ → cannot be used to leave an empty caption (but ⌘ ← works to leave an empty caption).
• Block boundary movements do not work to enter button text (you cannot reach the button text using the ⌘ arrow keys but arrow keys alone work in this case).
• No block boundary movements can be used to exit the button URL field.

This is what I found after auditing the demo post which contains the following blocks:

• Button
• Cover
• Gallery
• Heading
• Image
• List
• Paragraph
• Pullquote
• Quote
• Separator
• Vimeo

[designsimply]

I propose closing this issue after creating separate issues for the following exceptions noted above:

1. Firefox ⌘ ← and ⌘ → block boundary movements (low priority)
2. Empty captions
3. Button block

@mtias @mcsf does that sound good to you?

Or do all blocks need to be audited? (list of blocks)

[waterplea]

On Windows you can navigate by word with Ctrl + Arrow keys. In Gutenberg this doesn't work (although works in case of selection by word with Ctrl + Shift + Arrow keys). To be honest, this is SO basic and SO needed that I'm surprised this was not marked as critical and the editor was released with this bug. You basically cannot edit text with keyboard because anyone who has any speed in text writing uses this all the time.

[afercia]

@waterplea thanks for your feedback. I'd totally agree testing on Windows would need some more care. Also totally agree basic operations like navigating and selecting text with the keyboard should work flawlessly and should be tested in a solid way.

The specific bug you've mentioned has been recently reported in #14170 and fixed in #14184. The fix will be included in the next release.

[paaljoachim]

Can we get a status update?
Thank you!

[mtias]

@ellatrix I've been thinking that for the ⌘ ↑ case, the first press works fine (moves to the top of the current block) but we should make it so the subsequent press moves to the top of the previous block. What do you think?

[ellatrix]

@mtias Maybe. I think that behaviour may make more sense for Alt+Arrow?

[mtias]

Would command+arrow then move to the start of the document? I think the issue now is that once on a block boundary, command+Arrow feels erratic.

[ellatrix]

Yes, Cmd+Arrow should move to the start of the document then, Alt+Arrow block by block.

[ellatrix]

I think this works mostly correctly now:

Cmd + horizontal arrow sets the caret at the start or end of the line.
Cmd + vertical arrow sets the caret at the start or end of the focussed input/rich text element.

But it won't let you move the caret to the first or last block. One idea could be to make it similar to how Cmd+A works:

• Select all the focussed input contents
• Press Cmd+A again, and it will select all the sibling blocks.
• Press Cmd+A again, and it will select the parent block and all its sibling blocks.
• Etc. until you're at the root.

I could enhance Cmd + arrow similarly so it first move to the start of the input, then the first block from the nested blocks, then the first block of the parent nested blocks, and so on.

But it seems the main issue is fixed here, it depends what "beginning of your content" means (in the post and site editor).