fix(SelectionContext): keep selection tooltip alive after plugin view re-creation

[resure]

Text below and fix itself is mostly ai-generated, but I've also checked suggested fix manually on my project that uses markdown-editor

---

The floating selection toolbar (WYSIWYG mode, non-empty selectionContext config) goes permanently dead after any host-side EditorState swap.

The bug

SelectionTooltip keeps two mutable flags on the extension instance — destroyed and _isMousePressed — and nothing re-arms them when its plugin view is re-created. ProseMirror re-creates every plugin view whenever state.plugins changes identity, and EditorState.create always builds a fresh plugins array — so any host-side state swap triggers this (e.g. an undo-history reset), even one that passes view.state.plugins through unchanged:

1. The swap destroys the plugin views → destroy() sets destroyed = true. The view is re-created immediately, but view() never resets the flag.
2. The next mousedown hides the tooltip, sets _isMousePressed = true, and arms a one-shot document mouseup listener.
3. That listener starts with if (this.destroyed) return — so _isMousePressed is never reset.
4. Every later update() exits at if (this._isMousePressed) return. The toolbar never appears again for the lifetime of the editor — no errors, nothing in the console.

Minimal reproduction:

// 1. Select text with the mouse → the floating toolbar appears. Fine.
// 2. Swap the state once:
view.updateState(EditorState.create({doc: view.state.doc, plugins: view.state.plugins}));
// 3. Click once anywhere in the editor.
// 4. Select any text, with mouse or keyboard → the toolbar never appears again.

Two related flaws in the same handler:

• The mouseup re-check passes the state snapshotted at mousedown, and update() skips when doc + selection are unchanged since then. But the mousedown just hid the tooltip — so a press-release cycle that keeps the selection (e.g. re-selecting the same word) strands the toolbar hidden over a live selection.
• The mouseup gate is armed for every button, but some presses never deliver a document mouseup at all — a right-click on macOS (the native context menu opens during mousedown and swallows the release), or a press that turns into a native drag (ends with dragend) — wedging _isMousePressed until the next completed left click.

The fix

• view(): re-arm destroyed and _isMousePressed when the plugin view is (re-)created — plugin views are re-created far more often than plugins are.
• mouseup: re-evaluate without the mousedown snapshot — "unchanged" must not mean "keep hidden".
• mousedown: arm the gate only for the primary button (a non-left press still hides, as before), and release it on dragstart.

The plugin-view update path keeps its prevState short-circuit — that one is correct (the hide-meta check runs before it).

Tests

The new index.test.ts drives the plugin through the public SelectionContext extension with a real EditorView in jsdom, including a real view.updateState(EditorState.create(...)) swap for the main scenario — so it exercises ProseMirror's actual plugin-view re-creation. On current main the baseline test passes and the four regression tests fail (one per flaw); with the fix all five pass. The package unit suite stays green.

Found in gravity-notes, which currently ships a vendored copy of this plugin with these fixes; also verified end-to-end there in a packaged app with the plugin's gate decisions instrumented (before: mousedown → mouseup → (nothing), toolbar dead; after: mousedown → mouseup → SHOW).

Summary by Sourcery

Fix SelectionContext tooltip behavior so the floating selection toolbar remains functional after editor state swaps and various mouse interactions.

Bug Fixes:

• Prevent the selection tooltip from becoming permanently disabled after plugin view re-creation by rearming internal state flags when the plugin view is created.
• Ensure the tooltip reappears after clicks that keep the document and selection unchanged instead of remaining hidden.
• Avoid wedging tooltip updates on non-primary mouse button presses that may not emit a corresponding mouseup event.
• Release the tooltip’s mouseup gating when a mouse press turns into a native drag sequence so subsequent updates are not blocked.

Tests:

• Add integration-style tests for SelectionContext using a real EditorView to cover state swaps, unchanged-click scenarios, non-primary button presses, and drag interactions.

[gravity-ui]