Make canvas selectable / keyboard binding implicit

[nikku]

Proposed Changes

Keyboard is now implicitly bound and Canvas is a focusable element.

This builds foundations to support cross-browser/application copy and paste and more general keyboard related UX enhancements.

This change introduces a predictable editing experience, simplifies the keyboard and ensures worry free interoperability with multiple editors and inputs on the page.

Focusable Canvas (c75285b)

The Canvas is now a focusable component, that is recognized accordingly by the browser, with all benefits for UX and interaction. New APIs are provided to allow restoring focus to the canvas.

Components that pull focus from the Canvas during modeling must ensure to restore the focus (if intended), via Canvas#restoreFocus.

Implicit Keyboard binding (b0f9a75)

Keyboard is now implicitly bound to the canvas element (svg). It provides behavior closer to native browser experience.

Previous calls to keyboard.bind(someElement) or configuration via keyboard.bindTo log a descriptive descriptive error:

---

Closes #661

[nikku]

This can be tried out via:

npx @bpmn-io/sr nikku/bpmn-js-native-copy-paste#keyboard-bind -c "npm run start"

What I did is to remove any input quirks but rely on canvas to be actually browser selected. As a side-effect though that means that we consistently need to select the canvas when modeling operations happen:

I do not see a simple way to accomplish this (yet).

---

At this point we have two options:

• 🅰️ ditch this approach and keep existing manual keybinding
• 🅱️ invest into consistently + properly re-focus the canvas

🅱️ is a requirement for cross browser copy + paste to work reliably so I'd argue we need to pursue this route anyway.

[barmac]

On MacOS, the focus state is persisted once I hover the canvas even if switch tab afterwards and come back. Is this is supposed to work like this? I am not opinionated but it would be logical to me that focus fades away when I move mouse outside without clicking.

[barmac]

Indeed, it's an out of scope feature to be fixed 😆

[marstamm]

When we implicitly bind to the canvas, does it imply that extensions that rely on the command stack need to catch and trigger undo/redo manually? I'm thinking about the Properties panel here, where the most common case was to bind the keyboard to a common container.

I tested it on Edge and it works as expected, no new issues found from my side

[nikku]

Found the following issues integration testing this against different libraries in our eco-system:

• dmn-js-drd: no issues (works out of the box)
• dmn-js-decision-table / literal expression editor: has it's own keyboard implementation ➡️ needs porting to similar bind behavior, i.e. either make the table selectable + bind to it.
• form-js: re-uses diagram-js keyboard but has no canvas ➡️ need to improve the bind / unbind behavior proposed in this PR to get the actual diagram container. Two ideas:
  • expose diagram with container in form-js, too
  • pass the container on diagram.init for components to catch it and do stuff with it (i.e . register/unregister key bindings)

[pinussilvestrus]

form-js: re-uses diagram-js keyboard but has no canvas ➡️ need to improve the bind / unbind behavior proposed in this PR to get the actual diagram container. Two ideas:

• expose diagram with container in form-js, too
• pass the container on diagram.init for components to catch it and do stuff with it (i.e . register/unregister key bindings)

Given we follow one of these approaches, would we also have to follow up with explicit keyboard bindings for the Forms Properties Panel?

I'm asking because we plan to make it independent from the editor (e.g. render it in an own container, as we do with the other properties panels, cf. bpmn-io/form-js#291).

[nikku]

[...] would we also have to follow up with explicit keyboard bindings for the Forms Properties Panel?

Absolutely. Taking it one step at a time here though. Blueprint for properties panel binding can be found here: bpmn-io/bpmn-js-properties-panel#739.

[nikku]

This is now available as a pre-release via diagram-js@9.0.0-alpha.1 and bpmn-js@10.0.0-alpha.1.