New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cmd [arrow] commands do not function as expected #5805

Open
markjaquith opened this Issue Mar 26, 2018 · 7 comments

Comments

Projects
None yet
7 participants
@markjaquith
Member

markjaquith commented Mar 26, 2018

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.

@Soean Soean added the Accessibility label Mar 28, 2018

@markjaquith markjaquith referenced this issue Apr 4, 2018

Closed

Keyboard shortcuts support #71

21 of 35 tasks complete

@danielbachhuber danielbachhuber added this to the WordPress 5.0 milestone May 19, 2018

@mtias mtias added the Writing Flow label Jul 18, 2018

@afercia

This comment has been minimized.

Contributor

afercia commented Sep 3, 2018

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

This comment has been minimized.

Contributor

afercia commented Sep 3, 2018

Also, worth considering the equivalent arrow commands on Windows.

@mtias

This comment has been minimized.

Contributor

mtias commented Nov 13, 2018

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

@mtias mtias added the Needs Testing label Nov 13, 2018

@mcsf

This comment has been minimized.

Contributor

mcsf commented Nov 15, 2018

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.

@mcsf mcsf removed the Needs Testing label Nov 15, 2018

@mtias

This comment has been minimized.

Contributor

mtias commented Nov 15, 2018

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.

@mtias mtias modified the milestones: WordPress 5.0 RC, Future: 5.1 Nov 15, 2018

@designsimply

This comment has been minimized.

Contributor

designsimply commented Nov 15, 2018

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

This comment has been minimized.

Contributor

designsimply commented Nov 15, 2018

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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment