Keyboard handling

[barklund]

Feature description

We need either to have:

1. Global-only keyboard handling, where elements can listen for desired keyboard presses (if focused)
2. Global keyboard handling for global-only interactions (copy, cut, paste, undo, redo, select all) and local keyboard handlers in individual focusable elements (delete, enter, exit, type).

Weigh pros and cons between the two solutions, get consensus and implement.

This is not about creating the actual keyboard shortcuts, but about creating the framework for adding them later.

Ping me @barklund, if you need more details on this.

---

Do not alter or remove anything below. The following sections will be managed by moderators only.

Acceptance criteria

• Select between global-only keyboard handling or global+local keyboard handling
• Implement the selection

Implementation brief

QA testing instructions

Demo

Changelog entry

[jauyong]

We need to be careful about making sure the text edit mode does not collide with keyboard shortcuts.

[spacedmonkey]

I think there are a different set of handlerings depending on if an element is selected or not.

When a element is selected I would expect the following.

• Arrow keys would move the element in that direction.
• ESC key would deselect element
• DELETE / backspace would remove the selected element.
• ENTER would make a text element editable.
• CTRL + C / X - Would cut and copy the current selected element.

When an element is selected in the media library

• ESC key would deselect element
• ENTER would insert the element into the editor and select this new element.

When a form element is selected in the sidebar.

• ESC refocuses to the selected element.

Globally
I would expect all elements to be able to be tabbed to, with hidden skip jump that take you to different sections quicker, such as the canvas.

Should DETELE / backspace remove the current page? Maybe after confirming with a dialog? Should all deleting of elements via DELETE / backspace require confirmation.

[dvoytenko]

To clarify, copy/paste are probably not the keyboard actions, but the direct copy/paste events, right?

Initially, it'd seem, for the canvas specifically, it'd be more convenient to have a single set of keyboard/clipboard handlers. But in the current model it might be hard to dispatch all types of actions. DELETE and such global actions should be easy enough to handle universally. But there might be some element-specific actions as well? How do you see it? Similar to your panels approach? E.g. something like this?

Image.actions = {
  'ACTION1': (properties, setProperties, dispatcher) => {...},
};

As far as cross-section keyboard mapping: not yet sure. I.e. perhaps Canvas needs to have its own keyboard/clipboard handler, and the side panel, media panel, etc - their own? The focus-based event handling could be more composeable for separate big panels.

[miina]

@barklund Whenever you have time, would you mind adding a short implementation brief to reflect the logic in #3897 as well?

[swissspidy]

This is the one issue that we missed during the migration.

Manually added it as GoogleForCreators/web-stories-wp#119 now. Please use that one for further conversations.