openSuggestionMenu: menu closes on the second typed character (single-transaction dispatch breaks queryStartPos)

从 editor/BlockNoteEditor.ts 中的 openSuggestionMenu 开始，将其 transaction 与 SuggestionPlugin.handleTextInput 进行比较。阅读 api/positionMapping.ts 以了解 queryStartPos 的映射行为，然后验证拆分 insert 和 metadata 的 dispatch 是否能让菜单在多字符拉丁文和西里尔文查询时保持打开，并与输入触发器路径一致。

Summary

A suggestion menu opened programmatically with editor.openSuggestionMenu(...) closes as soon as a second character is typed into it. The same menu opened by typing the trigger character filters normally. This makes openSuggestionMenu unusable for any programmatic entry point that expects the user to then type a query.

Version: @blocknote/core 0.33.x (React 18 line), reproduced in Chromium.

Impact

We hit this on the side-menu «+» button, which for us is the only way to reach the slash menu on a Russian ЙЦУКЕН keyboard layout — that layout has no / key at all, so «click +, then type» is the whole route. Every slash item is equally affected. It is not layout-specific though: it reproduces with plain Latin keys.

Reproduction

Open the slash menu programmatically and type subp one real keystroke at a time:

editor.setTextCursorPosition(someEmptyBlock);
editor.openSuggestionMenu("/", { deleteTriggerCharacter: true });

Observed, recording whether the menu is open after each keystroke together with the caret's text node:

s : open   "/s"@2
u : CLOSED "/su"@3
b : CLOSED "/sub"@4
p : CLOSED "/subp"@5

Note the document is correct throughout — the trigger character is in the block and the caret is after the query. The menu is simply gone after the second character. Typing /subp by hand in the same editor filters correctly.

deleteTriggerCharacter is not the variable: without it the character is never inserted and it fails the same way; with it the document is right and it still fails.

Cause

openSuggestionMenu does the insert and the plugin meta in one transaction:

// editor/BlockNoteEditor.ts
this.focus();
this.transact((tr) => {
  if (pluginState?.deleteTriggerCharacter) { tr.insertText(triggerCharacter); }
  tr.scrollIntoView().setMeta(this.suggestionMenus.plugins[0], { … });
});

The native path in SuggestionPlugin.handleTextInput dispatches two:

view.dispatch(view.state.tr.insertText(text));
view.dispatch(view.state.tr.setMeta(suggestionMenuPluginKey, { triggerCharacter: snippet }).scrollIntoView());

That matters because the plugin's apply() builds queryStartPos inside the opening transaction's own apply:

const trackedPosition = trackPosition(
  editor,
  newState.selection.from - suggestionPluginTransactionMeta.triggerCharacter.length,
);
…
queryStartPos: () => trackedPosition() + triggerCharacter.length,

and trackPosition slices the editor's accumulated mapping at mapping.maps.length as read at that moment (api/positionMapping.ts). Whether the opening transaction's own map falls inside or outside that slice differs between the one-dispatch and two-dispatch shapes, so queryStartPos() drifts and the next keystroke fails the plugin's own guard:

newState.selection.from < prev.queryStartPos() ||
!newState.selection.$from.sameParent(newState.doc.resolve(prev.queryStartPos()))

The resulting plugin state is otherwise identical field for field between the two paths:

Confirmation

Replicating handleTextInput's two-transaction shape from application code fixes it completely — multi-character Latin and Cyrillic queries both filter, and the menu matches the typed-/ menu exactly:

const plugin = editor.suggestionMenus.plugins[0];
editor.transact((tr) => tr.insertText("/"));
editor.transact((tr) => tr.setMeta(plugin, { triggerCharacter: "/" }).scrollIntoView());

Forcing those two back into a single transaction reproduces the failure exactly, with everything else unchanged — that is the only variable.

Suggested fix

Split the dispatch inside openSuggestionMenu so the meta is set in a transaction after the insert, matching handleTextInput. Applications otherwise have to reach for editor.suggestionMenus.plugins[0] as a meta key to get a working programmatic entry point, which is what we have had to do.

Happy to open a PR if the approach looks right.