[brunosmm]

What and why

Closes #114

setContent(content, { resetHistory: true }) unregistered and registered the history plugin again. That produces a new state.plugins array, so ProseMirror's EditorView.updatePluginViews destroyed and recreated the view of every plugin (bubble menus, drag handle, slash commands...) on each content replacement, and the history plugin moved to the end of the plugin order.

resetHistory now finds the history plugin in editor.state.plugins (its key starts with history$) and dispatches one transaction with tr.setMeta(historyPlugin, { historyState: historyPlugin.spec.state.init({}, editor.state) }) and addToHistory: false. prosemirror-history returns that historyState from its apply, so the history is replaced while the plugin list, its order and every plugin view stay as they are. No-op when there is no history plugin (undoRedo disabled).

How it was tested

Two new tests in tests/set-content.spec.ts (Chromium and WebKit): after setContent(..., { resetHistory: true }) on an editor with a registered test plugin, editor.state.plugins keeps its identity, and the test plugin's view destroy is not called. Both fail on upstream/main and pass with the fix. The existing resetHistory test still covers undo and redo being unavailable and new edits being undoable.

Locally: npm run lint, npm run build:lib and npm run test:e2e -- --project=chromium --project=webkit pass (383 passed, 25 skipped). Firefox is left to CI.

Checklist

• npm run build:lib, npm run lint and npm run test:e2e pass (Chromium and WebKit locally, Firefox in CI)
• Tests fail without the change and cover every entry point it touches
• Change fragment changes/fixed.reset-history-plugin-views.md added
• Docs updated (no API or documented behavior change besides the fix)
• New user-facing strings added to every built-in locale (none added)

🤖 Generated with Claude Code