Bug(BlockNote) Drag and drop of table blocks broken

[ihordubas99]

Ticket

https://community.openproject.org/projects/communicator-stream/work_packages/71900

What are you trying to accomplish?

Fix a crash that occurred when drag-and-dropping a table block in the BlockNote editor while in collaborative (Yjs) mode. The editor would crash and the table would disappear entirely.

Screenshots

demo-github.webm

What approach did you choose and why?

Root cause

This is a race condition between a Yjs transaction and a ProseMirror DnD transaction. When a user drags a table, y-prosemirror's sync-plugin fires _forceRerender on BlockNote while ProseMirror hasn't finished moving the block yet. At that moment, BlockNote's internal useMemo tries to read block.id - but block is undefined because it hasn't been mounted in its new position yet. This results in TypeError: Cannot read properties of undefined (reading 'id').
The error originates inside blocknote-react.js - our code is not present in the stack trace at the point of the crash. This is an upstream bug in BlockNote: their internal useMemo does not guard against undefined blocks during concurrent Yjs/ProseMirror transactions.

Fix

Added an ErrorBoundary component to op-blocknote-extensions and wrapped
OpBlockNoteEditor with it inside OpBlockNoteContainer. When BlockNote
crashes, the ErrorBoundary catches the error and performs a soft remount
of the editor after 50ms. The user sees no disruption — the table remains
in its new position because Yjs had already persisted the change before the
render crash occurred.

The boundary only triggers a remount for the known BlockNote bug, identified
by matching both the error message and useMemo in the stack trace:

• Chrome/Edge: Cannot read properties of undefined (reading 'id')
• Firefox: can't access property "id", r.block is undefined

useMemo is a React API name and is never minified, making it a stable
anchor regardless of how the bundler renames BlockNote's internal files.
Matching both conditions avoids swallowing unrelated crashes - if the error
does not match the known pattern, hasError stays true and the fallback
is shown, so real bugs remain visible during development.

This is intentionally a workaround. The error is left visible in the console
so we can monitor when BlockNote fixes this upstream and remove the boundary.

The error is intentionally left visible in the console so we can monitor if
it disappears once BlockNote fixes this upstream.

Merge checklist

• Added/updated tests
• Added/updated documentation in Lookbook (patterns, previews, etc)
• Tested major browsers (Chrome, Firefox, Edge, ...)

[wielinde]

@ihordubas99 Did you consider reporting that bug upstream at BlockNote?

[judithroth]

Like we said in the daily, this fix should preferrably go upstream (BlockNote directly), or, if that is not possible, be fixed in OpenProject.