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.

The following shows how we may mitigate this: Whenever the canvas is mouse hovered we re-focus the canvas.

For debugging purposes I added a solid blue focus outline (solid blue => receives keyboard events + can copy + paste).

Try out via

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

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.

Cf. recording

#662 (comment)

I guess so. Keyboard inputs also don't magically unfocus once you leave with the mouse. The existing implementation works in the exact same way, or at least should work in the same way.

Hmm I don't like the infinite scrolling of the canvas which triggers once you paste outside of the canvas, but this solution is still an improvement compared to what we have right now. Thus, 👍 from me.

Fortunately infinite scrolling is an existing feature (cf. demo.bpmn.io):

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

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

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?

Exactly. The related hacks are all gone from the code base. If you want to trigger undo/redo via keyboard shortcuts you have to implement that yourself (i.e. attach a respective listener on the properties panel).

@philippfromme Given that there is a little bit of blinking during focus/unfocus going on we could decide to ditch the focus outline. What do you think?

While I was able to break the focus-on-hover on Safari, it's due to some element.hover bug – which is IMO an edge case we shouldn't care about.

Regarding the cross-browser copy and paste, on MacOS I am able to copy and paste across single browser tabs or even windows, but I cannot do that between different browsers (Safari -> Chrome, Chrome -> Safari). The clipboardData appeared to be empty when I tried to debug it.

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)

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).

[...] 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.

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

I rebased this branch with the current main, I saved the previous state in this other branch since we had some conflicts while rebasing it

@nikku do you have a (non-binding) ETA for this PR? 😅

Just so I can update the team

@vsgoulart I'm going to assess it this week.