ueberdosis/tiptap

Affected Packages @tiptap/markdown Tiptap Version 3.31.4 Browser Used Not browser-specific What happened? Link hrefs parsed from Markdown keep HTML entities undecoded, while the link text is decoded. &amp; in a URL ends up as a literal &amp; in the href attribute. Because the serializer writes & in text as &amp;, this also breaks a plain round trip: typing a bare URL with a query string, saving, and loading again produces a broken link. const editor = new Editor({ extensions: [StarterKit, Markdown] }) editor.commands.setContent('https://example.com/?a=1&amp;b=2', { contentType: 'markdown' }) Markdown Link text href https://example.com/?a=1&b=2 https://example.com/?a=1&b=2 https://example.com/?a=1&b=2 https://example.com/?a=1&amp;b=2 https://example.com/?a=1&b=2 https://example.com/?a=1&amp;b=2 <https://example.com/?a=1&amp;b=2> https://example.com/?a=1&b=2 https://example.com/?a=1&amp;b=2 [x](https://example.com/?a=1&amp;b=2) x https://example.com/?a=1&amp;b=2 Round tr

Package: @tiptap/extensions 3.31.3 (same code in 3.31.4) Steps to reproduce Configure Placeholder.configure({ includeChildren: true }), with showOnlyCurrent left at its default (true). Put the caret in an empty paragraph at the end of the document and press Enter twice, so there are three empty paragraphs. Press ArrowUp. Expected Only the paragraph that holds the caret shows the placeholder. Actual The paragraph the caret just left keeps its placeholder, so more than one empty paragraph shows it. More placeholders pile up as the caret moves. This did not happen in v2, which rescanned the whole document. Cause includeChildren: true selects the incremental state field (createPlaceholderStateField). After each transaction, collectRescanRanges builds the top-level block ranges to rescan from resolveTopLevelRange, then passes them through toContentRelativeRange: function toContentRelativeRange(doc, range) { return { from: Math.max(0, range.from - 1), to: Math.min(doc.content.siz

Affected Packages extension-mention, markdown Tiptap Version 3.30.3 Browser Used Not browser-specific What happened? When a mention label contains a double quote, saving to Markdown and loading it again cuts the label off. The text after the quote is lost without any error. The mention is written as label="..." with the value put in as is, and the parser stops at the first closing ". Repro with MarkdownManager and the Mention extension (vitest, no editor needed). Serialize this doc: { type: 'doc', content: [{ type: 'paragraph', content: [{ type: 'mention', attrs: { id: 'u1', label: 'Bob "The Builder" Smith' } }] }] } Output of serialize: [@ id="u1" label="Bob "The Builder" Smith"] parse of that output gives the attrs { id: 'u1', label: 'Bob ' }. Other results: label a"b comes back as a label O'Brien is fine Found on main (13675ea), @tiptap/extension-mention 3.30.3. AI disclosure: I found this with Claude's help and confirmed it by running the repro above. I would like to send a small

Affected Packages suggestion Tiptap Version 3.30.3 Browser Used Not browser-specific What happened? findSuggestionMatch builds a regular expression from allowedPrefixes without escaping the entries: new RegExp(`^[${allowedPrefixes?.join('')}\0]?$`) So any prefix that is special inside a character class breaks the match. allowedPrefixes: [' ', '-'] throws: Invalid regular expression: /^[ - ]?$/: Range out of order in character class allowedPrefixes: [' ', ']'] never matches, so the suggestion never opens after ] a backslash and ^ are also read as regex syntax ['-', ' '] happens to work, so the result depends on the order of the array Small repro (plain ProseMirror schema, no editor needed). Doc is "hi @bob", cursor at the end: findSuggestionMatch({ char: '@', allowSpaces: false, allowToIncludeChar: false, allowedPrefixes: [' ', '-'], startOfLine: false, $position }) With [' '] it returns { range: { from: 4, to: 8 }, query: 'bob' }. With [' ', '-'] it throws. Found on main (13675ea), @

Affected Packages @tiptap/extension-list, @tiptap/markdown Tiptap Version 3.31.3 Browser Used All (reproduced in Chromium and in Node with happy-dom) What happened? When Markdown with a fenced code block inside an ordered list item is parsed, each code line gets one extra leading space. The error grows with every round-trip: getMarkdown() writes the extra space back, and the next setContent(..., { contentType: "markdown" }) adds one more. Saving the same document 3 times gives 4 extra spaces. const input = "1. Item:\n\n ```\n code line\n ```\n"; const editor = new Editor({ extensions: [StarterKit, Markdown], content: input, contentType: "markdown" }); // code block text: " code line" (CommonMark reference: "code line") editor.commands.setContent(editor.getMarkdown(), { contentType: "markdown" }); // " code line" editor.commands.setContent(editor.getMarkdown(), { contentType: "markdown" }); // " code line" The same happens with 10. markers. Expected Behavior The code block t