markdown_parser: unclosed `<u>` markers pair via the emphasis algorithm and delete surrounding text

[tkshsbcue]

Summary

parse_markdown silently deletes text when a <u> underline marker is left unclosed and another <u> appears later in the same line. The two <u> markers are matched against each other as an emphasis pair and consumed, taking the text around them with them.

Reproduction (against the real parser)

Input	Expected (literal round-trip, like an unclosed *)	Actual
<u><u>	<u><u>	empty line — all text gone
<u>a<u>	<u>a<u>	a (both <u> deleted)
a <u>word<u> b	a <u>word<u> b	a word b (both <u> deleted)

assert_eq!(parse_markdown("<u><u>").unwrap().raw_text(), "<u><u>\n"); // fails: left is "\n"

Root cause

<u> is tokenized as an UnderlineStart delimiter (crates/markdown_parser/src/markdown_parser.rs, the InlineToken::Delimiter arm) and pushed onto the shared delimiter stack with can_close set from the right-flanking rules (Delimiter::new). As a result process_emphasis sees two <u> markers as a matchable opener/closer pair — can_open_for passes because they share kind == DelimiterKind::UnderlineStart — and the opener.kind == UnderlineStart branch in process_emphasis consumes both markers and removes their text nodes.

Underline is only ever supposed to be closed by an explicit </u>, which is handled separately by parse_underline (it never goes through can_open_for). So pairing two <u> openers through the emphasis path is always wrong; an unclosed <u> should round-trip to literal text, exactly like an unclosed *.

Impact

parse_markdown is the main renderer for agent output and markdown-viewer content, so a partial/streamed <u> or two <u> tags silently drop the literal text. This is data loss in rendered output, not a crash.

Notes

• Crate-scoped and reproducible with a pure unit test (no UI needed).
• I have a small fix ready (make can_open_for reject UnderlineStart; ~8 lines) with regression tests for the cases above, and all existing markdown_parser tests still pass. Happy to open a PR once this is labeled ready-to-implement.

Operating system

All (platform-independent parser logic)

[oz-for-oss]

@tkshsbcue

Here's what I found while triaging this issue:

Source inspection supports this as a parser bug: two <u> start markers can be treated as a matched underline pair and stripped instead of remaining literal text.

Maintainer details

I concluded that unclosed <u> underline start tags can be paired by the markdown emphasis algorithm, causing the literal markers to be stripped from rendered text..

Triage summary

This looks like an actionable markdown parser bug. The observed symptom is that unclosed <u> start markers can be treated as a matched underline delimiter pair and removed, so literal text such as <u><u> or a <u>word<u> b does not round-trip as expected.

Evidence

• The report provides minimal crate-level reproductions against parse_markdown, without UI or environment dependencies.
• In crates/markdown_parser/src/markdown_parser.rs, parse_inline_token_underline_start turns <u> into InlineToken::Delimiter { kind: DelimiterKind::UnderlineStart, count: 1 }.
• Delimiter::new computes can_open and can_close for UnderlineStart using the same left/right-flanking machinery as emphasis delimiters.
• The final process_emphasis(&mut state, None) pass can then match two UnderlineStart delimiters through can_open_for, apply underline styling, and remove the delimiter text nodes.
• Explicit underline closure with </u> is handled separately by parse_underline, so pairing two <u> starts in the emphasis path appears unintended.

Duplicate check

I searched open issues across the repository and checked recently closed issues from the last seven days for exact parser/tag terms. I found related but distinct issues such as #12691 (markdown rendering feature request) and #12500 (closed long-delimiter overflow bug), but no matching duplicate for unclosed <u> start tags being consumed as a pair.

Validation notes

I attempted to run a targeted cargo test -p markdown_parser ... command, but this sandbox does not have cargo installed. The triage confidence is based on the minimal reproduction in the report plus direct source inspection of the current parser implementation.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[oz-for-oss]

This issue has been labeled ready-to-implement and is open for contributions involving code changes. If you'd like to tackle it, feel free to open a pull request against this issue. You can also comment @oz-agent on this issue to have the bot draft an implementation PR automatically.