You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit e8c0831
Browse filesBrowse the repository at this point in the historyBrowse files
fix: don't crash when a node view's getPos() is stale
`getPos()` is derived from ProseMirror's view-desc tree, but
`updateStateInner` assigns the new state before it reconciles that tree.
Anything rendering part-way through reconciliation - a re-entrant dispatch
from a node view effect, TipTap's `flushSync` while mounting a node view -
therefore reads a position that no longer lines up with `view.state.doc`.
Resolving it threw `RangeError: Position N out of range`, or
`Node should be a bnBlock, but is instead: doc` when the position was in
range but pointed at the wrong node. Under React 19 that tears down the
consumer's tree rather than being rethrown.
Upstream considers this TipTap's problem (ProseMirror/prosemirror#1532)
and TipTap considers `flushSync` unavoidable, so recover on our side:
- core `getBlockFromNodeView`: falls back to building the block from the
node alone. Reached only when a re-entrant dispatch superseded the
document, so the node is gone from it and there is no container to read
an id from - `type`, `props` and `content` are correct, `id` is freshly
generated and belongs to no block.
- react `useNodeViewBlock`: falls back to the last block it resolved,
seeded from the one core resolved at construction.
Both are silent and transient; ProseMirror rebuilds the node view against
the current document immediately after, so a stale frame is invisible
where a throw is not.
0 commit comments