fix(mobile): chat folds stay closed until tapped, as on web and desktop#28072

🟠 High lib/markdownDetails.ts:34

A </details> inside a fenced code example in an HTML block closes the fold early, leaving the remaining text outside the fold and splitting the code fence. node.value.matchAll(DETAILS_TAG) scans the entire HTML node, including code ranges that CommonMark keeps inside that node; exclude code ranges before matching tags.

Fixed in 043c2ecb31. Fold tags now come from markdownHtmlTags, which already skips fences and code spans inside HTML blocks. I added a test with </details> inside a fenced example in the fold.

🟠 High threads/ThreadFeed.tsx:1228

A <details> fold stops hiding its content when it contains an artifact-template directive: the artifact card and subsequent body text render outside the fold, so tapping the summary cannot hide them. AssistantMarkdownContent splits artifact templates before AssistantMarkdownBlocks parses details, leaving the closing fold boundary in a later segment; parse details first and render artifact-aware content inside each fold.

Fixed in 043c2ecb31. Folds are now split first, and artifact templates are split inside each fold's body and each part between folds. A card inside a fold now stays hidden with it.

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

External image Minor · Functional Correctness · Quick win

Do not treat tags inside HTML comments as folds.

For <!-- <details> -->\n\nVisible answer., the comment is an HTML node, so this scan treats its text as an opening tag. The parser then puts the visible answer behind a new “Details” button. Exclude comment contents from tag matching, and add this input to the existing ignored-tag test. (github.com)

Already handled by 043c2ec, which this review predates. Fold tags now come from markdownHtmlTags, which matches a whole comment as one token, so a <details> inside it is never seen. I added your input to the ignored-tag test in b0d27198b5.

@Umais-Adeed You’re right. markdownHtmlTags matches the whole HTML comment as one token, and the anchored DETAILS_TAG pattern rejects that token. The ignored-tag test also includes the exact input.

My finding used the older implementation. I withdraw it. I verified the source and test case by inspection; I did not run tests.

Review thread resolved.

_{You are interacting with an AI system.}

External image Major · Functional Correctness · Heavy lift

Recognize a closing tag inside a paragraph.

For <details>\n<summary>Plan</summary>\n\nDone </details>\n\nNext step, the closing tag is inline HTML inside a paragraph. This loop checks only root-level html nodes, so it leaves the fold open through “Next step.” The renderer then hides text that follows the fold. Account for inline closing tags when a top-level fold is active, without treating inline opening tags as new top-level folds. (spec.commonmark.org)

✅ Confirmed as addressed by @Umais-Adeed

Fixed in b0d27198b5. While a fold is open, tags inside paragraphs now count toward closing it. A fold still opens only at block level, so an inline <details> outside a fold stays Markdown. I added your example as a test.

@Umais-Adeed The inspected code handles paragraph-level closing tags while a fold is open. Inline <details> outside a fold still stays Markdown. The regression test covers the reported example and keeps “Next step” outside the fold.

The checkout was at b0d27198b5, not fc963224a3. I verified the fix by inspection; I did not run tests.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Strip a closing tag only when the scan found one.

An unclosed fold can end with </details> inside an unfinished code fence. The tag scan leaves that text in code, but this suffix match removes it from the fold body. Record whether the scan closed the fold, and use that result instead of matching the body suffix. (raw.githubusercontent.com)

✅ Confirmed as addressed by @Umais-Adeed

Fixed in c5b7b9cfbd. Each fold now records the length of the closing tag the scan matched (zero when unclosed), and only that is removed from the body. An unfinished fold keeps a </details> inside unfinished code. I added that case to the streaming test.

@Umais-Adeed Verified in the current source. closeTagLength is zero for unclosed folds, so body extraction preserves </details> inside unfinished code. The streaming test covers this case. I inspected the test but did not run it.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Check the open attribute, not the full tag text.

For <details title="tap to open">, /\sopen\b/i matches the title value. The fold then starts expanded although it has no open attribute. Parse attribute names before setting open; add this case to the existing open-state test. (raw.githubusercontent.com)

✅ Confirmed as addressed by @Umais-Adeed

Fixed in c5b7b9cfbd. Quoted attribute values are blanked before checking for open, so title="is open" no longer expands the fold. I added a test for it.

@Umais-Adeed Thanks. I verified that quoted attribute values are removed before the open check. The regression test covers title="is open" and expects open: false. This addresses the reported case. I did not run the tests.

If you found this review helpful, would you consider giving us a shout-out on X?

Thank you for using CodeRabbit!

Review thread resolved.

_{You are interacting with an AI system.}

External image Minor · Functional Correctness · Quick win

Match the complete details tag name.

If a reply contains a standalone <details-panel> tag, \b matches before the hyphen. The scan treats that custom tag as a fold and hides its body behind a disclosure control. Require whitespace, /, or > after details instead. CommonMark permits standalone custom tags as HTML blocks. (spec.commonmark.org)