feat(spx-gui): fixed the issue of merging line breaks after using a custom self-closing tag

[Overu]

Closed #2472

[gemini-code-assist]

Summary of Changes

Hello @Overu, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses a specific rendering anomaly within the MarkdownView component where custom self-closing tags, when immediately followed by a line break and text, would lead to an incorrect merging of content. By introducing a new preprocessing step, preprocessInlineComponents, the system now correctly interprets and separates such content into distinct paragraphs, significantly improving the accuracy and predictability of Markdown rendering for custom components.

Highlights

• Markdown Preprocessing Logic: Introduced a new preprocessInlineComponents function to specifically handle and correct the rendering of custom self-closing tags followed by line breaks and text in Markdown. This ensures proper paragraph separation instead of unintended merging into a single HTML block.
• Enhanced Markdown Rendering: Fixed an issue where custom self-closing tags, when followed by a newline and text, would incorrectly merge the subsequent text into the same HTML block. The new logic ensures that such text is treated as a distinct paragraph.
• Comprehensive Test Coverage: Added a dedicated test suite for preprocessInlineComponents covering various scenarios, along with new integration tests for MarkdownView to validate the correct rendering behavior of custom self-closing tags.
• Minor Text Update: A small textual correction was made in a tutorial constraint message.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

The pull request introduces a new preprocessing step to correctly handle line breaks after custom self-closing tags in Markdown, which addresses the issue of merging line breaks. The new preprocessInlineComponents function and its integration into parseMarkdown are well-tested. A minor typo was found in a constraint description.

[xgopilot]

Critical: ReDoS Vulnerability & Performance Issue

This line has two critical issues:

1. ReDoS (Regular Expression Denial of Service): The pattern ([^\n]*\\S[^\n]*) can cause catastrophic backtracking on inputs with long sequences of whitespace.

2. Performance: Creating new RegExp() inside the forEach loop means the regex is recompiled for every tag name on every parse. During streaming updates, this causes significant overhead.

Recommended fix:

export function preprocessInlineComponents(value: string, tagNames: string[]): string {
  if (!value || tagNames.length === 0) return value
  
  // Precompile patterns once with bounded quantifiers to prevent ReDoS
  const patterns = tagNames.map(tagName => {
    const escaped = tagName.replace(/[.*+?^${}()|[\]\\]/g, '\\$&')
    return new RegExp(`(<${escaped}[^>]{0,500}/>)[ \\t]{0,100}\\r?\\n([^\\n]{0,1000}\\S[^\\n]{0,1000})`, 'g')
  })
  
  return patterns.reduce((acc, pattern) => acc.replace(pattern, '$1\n\n$2'), value)
}

This also adds regex escaping for tag names and input validation.

[Overu]

涉及到跨多行的处理，用正则不太合适，改为代码解析。

[xgopilot]

Code Review Summary

This PR successfully addresses issue #2472 with good test coverage and clear documentation. However, there are critical security and performance issues that must be addressed before merging.

Critical Issues:

• ReDoS vulnerability in regex pattern (line 158) - can freeze browser with malicious input
• Performance: Regex recompiled in loop during streaming causes significant overhead
• Typo: "frist" → "first" still present in tutorial-course-abandon.ts:14

Important Issues:

• Missing regex escaping for tag names (potential injection)
• Documentation example inconsistency (component name changes)
• Test descriptions say "merge" but function "separates"

The implementation is solid with excellent test coverage, but the regex pattern needs immediate attention for both security and performance. See inline comments for detailed recommendations.

[qiniu-ci]

This PR has been deployed to the preview environment. You can explore it using the preview URL.

Warning

Please note that deployments in the preview environment are temporary and will be automatically cleaned up after a certain period. Make sure to explore it before it is removed. For any questions, contact the XBuilder team.

[nighca]

只处理 self-closing tag 的话会导致

• <foo />\nxxx
• <foo></foo>\nxxx

这俩的渲染结果不一致吗？我们现在对于 custom components，预期两种姿势都是支持的

[Overu]

会,

<foo />\nxxx会被处理成

<html_block />
<paragraph>xxx</paragraph>

<foo></foo>\nxxx会被处理成

<paragraph>
  <html_inline></html_inline>
  xxx
</paragraph>

但是两者通过stream输出时，不管解析到<foo />还是<foo></foo>，都会被渲染为

<html_block />

都会导致两次mounted。

当时只处理<foo />\nxxx是因为只有self-closing + \n + xxx才会出现解析问题

<html_block>foo xxx</html_block>

其他情况都是正常的，如果现阶段处理<foo></foo>\nxxx的情况，我担心会影响到highlight-link

理想情况是告诉mdast，foo是inline，在解析的时候就当成html_inline处理。
这需要扩展mdast。

[nighca]

那我们就按区分 inline & block 来处理吧

我没理解错的话，那样最后 custom element 会分成三种：1) inline 2) block 3) raw 对吧？

这需要扩展mdast

这里说的扩展具体是指？我记得之前在处理 raw 的时候我简单看过，没看到不去修改它的代码来支持自定义 raw element 的做法，所以后来通过 <pre is="xxx" 的方式来变相达到目的

[Overu]

我没理解错的话，那样最后 custom element 会分成三种：1) inline 2) block 3) raw 对吧？

对的。

raw element是利用mdast对pre标签的处理特性来实现格式还原。

扩展mdast通过mdast的extension来自定义解析，类似

const mdast = fromMarkdown(value, {
    mdastExtensions: [
      {
        enter: {
          some(token) {
            this.enter({ type: 'html', value: 'some' }, token)
          },
        },
        exit: {
          some() {

          }
        }
      }
    ]
  })

另一种是参照raw element，把inline的标签伪装成<a is="xxxx" ></a>

[nighca]

扩展mdast通过mdast的extension来自定义解析

嗯这样可行的话可以把 raw 的做法也换成基于 extension，要比 pre 的做法稍微好一些

[Overu]

好的👌