markdownToHtml freezes on complex HTML comments

[ymkil]

Environment

• Package: markdown
• Version: 7.3.0

---

❗ Problem Description

When using markdownToHtml on a valid Markdown input that contains a multi-line HTML comment block with list markers and Markdown formatting inside the comment, the function hangs indefinitely (appears to freeze). This issue is reproducible and seems to be caused by catastrophic backtracking in the InlineHtmlSyntax regex for HTML comments.

---

✅ Expected Behavior

The comment block should be recognized as a valid HTML comment (as per CommonMark spec) and skipped or retained in output without affecting the parsing process. Even if the comment body contains unusual structure, the parser should not hang.

---

❌ Actual Behavior

The parser gets stuck and does not return, causing Flutter to freeze during markdownToHtml. No exceptions are thrown — the function simply fails to complete.

---

🧪 Reproduction Code

import 'package:markdown/markdown.dart';

void main() {
  const input = '''
くくる。<!-- consider:
①. 思考本次推进所需的专家数据库：
    - **脚本家**: 负责评估角色间的对话冲突、戏剧张力以及情节点设置的有效性。确保两个角色之间的对立关系能够通过对话和行动有效地展现出来，而不是停留在设定层面。
    - **空间设计师/建筑师**: 负责构想和修正密室的环境细节。一个没有门窗、只有特定家具的房间，其材质、光线、布局都会对角色的心理产生巨大影响。专家需要确保环境描写能够增强故事的幽闭感和非现实感。
    - **表演指导**: 负责分析角色的行为逻辑和微表情。颜慎的高傲和嘴硬背后是怎样的心理动机？她的站姿、眼神、手部的小动作应该如何表现她的真实心态，而不是一个标签化的“高傲女”。
    - **恋爱小说家 (专攻对立关系)**: 负责审视从敌对到亲密关系的转变逻辑。虽然目前只是开始，但最初的互动是后续情感变化的基础。专家会关注如何让“被迫亲吻”这个外部压力，有效地转化为内部情感变化的催化剂。

②. 专家如何修改问题：
    - **脚本家**: 指出沐芊的质问虽然符合人设，但略显直接。建议让颜慎的回应更具“阴阳怪气”的特色，不仅仅是反驳，而是通过反问和嘲讽来升级冲突，例如：“你脑子进水了？我要是有这本事，第一个就是把你从我眼前变走。”这比单纯说“不是我干的”更有角色魅力。
    - **空间设计师**: 建议不要只说“没有门”，而是要描写墙壁的质感，比如“墙壁光滑得像一整块打磨过的骨瓷，连一丝缝隙都找不到”，以此来强调这个空间的超现实和不可逃脱性。同时，那张KingSize大床应该被描述为房间里唯一的“柔软区域”，与周围的坚硬形成对比，暗示着唯一的“出路”也伴随着柔软的、亲密的接触。
    - **表演指导**: 建议颜慎在说出挑衅的话语时，可以有一个不自觉的小动作，比如用指尖轻轻敲击桌面，或者整理了一下自己并无褶皱的衣角。这能表现出她试图用无聊或不屑的姿态来掩盖自己对当前未知情况的一丝不安。
    - **恋爱小说家**: 提出即使是敌对关系，在面对共同的、荒诞的困境时，也会产生一种微妙的“共犯”感。建议颜慎在挑衅的同时，眼神深处可以流露出一丝“我们现在是一条船上的蚂蚱”的意味，而不是纯粹的敌意。

③. 回避词及其规避策略：
    - **a. 抽象概念具象化的表属性附加连接短语 (例: 带着…的眼神)**: 规避策略是直接描述行为或状态。不说“她用带着嘲讽的眼神看着我”，而是说“她嘴角撇了撇，视线从我头顶扫到脚尖，像在打量一件过季的商品。”
    - **b. 抽象概念具象化的描述性连接短语 (例: …的气氛)**: 规避策略是通过环境和角色的互动来营造氛围。不说“房间里充满了尴尬的气氛”，而是描述“空气安静得能听到彼此的呼吸声，颜慎敲击桌面的声音一下一下，显得格外刺耳。”
    - **c. (NFSW) 对身体和性器官的隐喻**: 尚未使用。
    - **d. (NFSW) 表示暴力和剧烈的形容词**: 尚未使用。
-->
''';

  final html = markdownToHtml(input); // This hangs
  print(html);
}

---

🔎 Root Cause (likely)

The regex inside InlineHtmlSyntax:

'<!--(?:(?:[^-<>]+-[^-<>]+)+|[^-<>]+)-->'

…is vulnerable to catastrophic backtracking on inputs that contain - characters (e.g., list items) within the comment body. With enough structure, it fails to resolve the pattern efficiently and loops indefinitely.

This regex assumes comments are simple and short — but valid HTML comments can include complex content (as per the CommonMark spec).

---

🛠️ Suggested Solutions

• Refactor the regex to be more robust — for example:

  r'<!--([\s\S]*?)-->'

  This matches all characters including newlines, lazily, and avoids nested patterns prone to backtracking.

• Alternatively, move to a non-regex approach for comment detection that tracks <!-- to --> boundaries directly, bypassing complex pattern matching.

---

📎 Additional Notes

• Disabling InlineHtmlSyntax or stripping comments manually avoids the issue — but is not an ideal workaround.
• Other users might encounter this when embedding design docs or notes inside comment blocks in Markdown.

---

🙏 Request

Please review the HTML comment handling logic in InlineHtmlSyntax, particularly the regex for <!-- -->. A more robust approach would greatly improve stability for production use.

Thank you for your work on this package!

---

[lrhn]

It doesn't hang, but it is incredibly slow. It takes ~15 seconds on my very capable desktop.

My first guess would also have been a RegExp with catastrophic backtracking, but just doubling the entries changes nothing.
Adding more - ** lines in an entry does do something, so it looks like that's the issue.

Taking just the ① block and removing one line, it parses in 300 ms. Adding back the fourth line it now takes 18 seconds. Adding a fifth line ... I haven't had the patience to wait for that to complete.

So let's look at the HTML comment RegExp:

r'<!--(?:(?:[^-<>]+-[^-<>]+)+|[^-<>]+)-->'

It's part of a larger RegExp where this is one alternative, which are distinguishable in the first three letters, so it's definitely this one that applies.

I see +)+ which is a sign of danger for catastrophic backtracking blowup. That comes from (?:[^-<>]+-[^-<>]+)+,
which is any text without < or > containing precisely one -, and one or more of those.

Yep, that is, as you said, the problem. The trailing [^-<>]+ of one repeat of the outer + can overlap with the leading [^-<>]+ of the next repetition. If it matches, that's awesome. If not, it goes through all possible ways to split the text between -s, each time trying the same thing again, which will still not match. And with multiple lines, so multiple -s, every time it fails all splits of the last line, it goes back and tries the next split of the previous line, and then it tries all splits of the last line again. With the same inevitable failure at the end where it sees a > or <.

A better RegExp matching the same thing would be:

r'<!--[^-<>]+-(?:[^-<>]+-)*?->'

It's the wrong thing to match, though. The actual linked CommonMark 3.0 specification is:

An HTML comment consists of <!-- + text + -->, where text does not start with > or ->, does not end with -, and does not contain --. (See the HTML5 spec.)

The most recent 0.31.2 specification says:

An HTML comment consists of <!-->, <!--->, or <!--, a string of characters not including the string -->, and --> (see the HTML spec).

(That's not the HTML syntax that it links to, but we're implementing CommonMark, not HTML.)

That'd be a RegExp like

r'<!--(?:-?>|[^]*?-->)'

Should probably only implement CM 3.0 for now, that's what the tests expect, so

r'<!--(?!-?>)[^\-]*-(?:[^\-]+-)*?->'

(no --s between <!-- and -->, not allowing <!--> or <!--->, so start with <-- not followed by > or ->, the followed by any characters until the first -, which is the either not followed by a -, then match until the next - and keep doing that, or it's followed by -> to end the comment.)

I made a fix.