Rich Text: Treat ctrl+d as delete

[jblz]

Description

Currently, pressing the delete button (fn+delete on the MacBook keyboard) at the end of a Paragraph / Rich-Text block results in a subsequent block merging with the selected one as shown in this screencap:

On the Mac (& in some other environments), pressing ctrl+d in a text-editor is functionally the same as pressing delete. Inside a block, this works appropriately (presumably by the OS control the browser is using): content to the right of the cursor is deleted.

However, the gutenberg conditional which handles deletions is not currently returning true, so onDeleteKeyDown does not get called.

This change adds ctrl+d to the list of key combinations which result in onDeleteKeyDown being called.
It also adds ctrl+h to achieve the opposite on the starting boundary of the text box (which merges in the other direction as per the "backspace" functionality (now called delete on the Apple keyboard)

How has this been tested?

• Run locally in Docker
• Create some Paragraph blocks
• Place the cursor in the middle of the block
  • Press ctrl+d
  • The text following the cursor is deleted
• Place the cursor at the end of a block with a subsequent Paragraph block
  • Press ctrl+d
  • The two paragraphs are merged and the text following the cursor is the start of the next block (behavior should be the same as pressing the "proper" delete key)
• Repeat the above with a non-text block (like an image block) following the Paragraph under test
  • Nothing should happen -- the non-text block should stay where it is

Types of changes

New feature

Checklist:

• My code is tested (manually, but it could use a unit test!)
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[jblz]

I think this would be ok to apply to all environments, but I don't have a non-Apple computer on which to test.

[ellatrix]

It would be cool if we could look at the input event instead and detect deleteContentForward and deleteContentBackward. This method would be more robust.

[jblz]

I'll try those out, thanks!

[ellatrix]

Thanks! The benefit of using that is that the OS doesn't matter. You could even have custom shortcuts and it would still work.

[jblz]

It looks like InputEvents don't get fired at the boundaries :-/

I tested like this:
document.querySelector( '.editor-rich-text__editable' ).addEventListener( 'input', e => console.log( e ) );

Events fire when inserting & deleting actually happens, but not if the keypress events don't actually result in an input change.

Is there another way we can access those properties?

[ellatrix]

Perhaps we could insert something to see what happens, but for now I'm ok with just looking at the keydown event.

[ellatrix]

Could we do something like const D = 'D'.charCodeAt( 0 );?

[jblz]

Updated w/ this approach (& to add ctrl+h support)

[ellatrix]

Looks like there is also ctrl+h for deleting to the left. Do you know of any other combination? Is this behaviour documented somewhere? Does this work for any OS, or only MacOS?

[jblz]

Thanks for taking a look, @ellatrix!

Looks like there is also ctrl+h for deleting to the left. Do you know of any other combination?

I'm just seeing that -- I don't know of any others. I use ctrl+d very often (since fn+delete requires two hands on modern Macbooks), so run up against this a lot. I never use ctrl + H since I can just press delete (né "backspace") with one hand.

Is this behaviour documented somewhere?

This is all I could find for official documentation on the Apple side: https://support.apple.com/en-us/HT201236

Does this work for any OS, or only MacOS?

I'm pretty confident it works elsewhere, but I don't currently have an environment to test.

[ellatrix]

Control-H: Delete the character to the left of the insertion point. Or use Delete.

[jblz]

Again, I'm not sure if this should be generally applied regardless of OS.

We should either take out the isAppleOS check or apply it to isReverseDeleteKeyboardEvent as well. Open to suggestions!

[jblz]

I went ahead and removed it for now so this is easier to test on other environments.

[ellatrix]

I've been thinking about this a bit more. Could a more general solution perhaps be to fire the proper key events if the OS/Browser doesn't?

[guarani]

Looks like this needs to be rebased with master and conflicts resolved to be testable on mobile since this PR pre-dates the monorepo changes.

[mcsf]

Closing as stale. Feel free to reopen with a refresh and thoughts on #15019 (comment).