Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
docs: fix markdown links not rendered inside GFM alert HTML blocks #46569
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
docs: fix markdown links not rendered inside GFM alert HTML blocks #46569
Changes from all commits
e9c6f6a18eca066dc23308771dde452632dad31d0fe51734fFile filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/diagnosing-bugs]
applyMarkdownTransformationuses a greedy[\s\S]*?regex to strip the outer<p>wrapper, butprocessSynccan emit multiple paragraphs (e.g. if the summary content has a blank line). In that case the result would begin with<p>and end with</p>\n, so the strip regex matches only the first-to-last</p>— potentially stripping intermediate</p><p>boundaries.💡 Safer approach
Strip only the leading and trailing
<p>tags independently:Alternatively, limit inputs to single lines so multi-paragraph summaries are not silently mangled.
@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/diagnosing-bugs] The closing-tag regex can match across mismatched open/close tags — e.g.
<summary>...</td>would be processed if both tags appear inINLINE_TEXT_TAGS.💡 Suggested fix
Capture the opening tag name and use a back-reference so only a matching close tag is accepted:
Without this, content between an
<li>and the next</summary>in a complex HTML block could be incorrectly reprocessed.@copilot please address this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The double-processing guard (
/<a[\s>]/i.test(content)) skips the entire tag content if it contains any existing anchor — including cases where a markdown link appears alongside an already-rendered<a>. In practice this is safe for build-time docs, but if a<summary>ever contains both an authored<a>and a markdown link, the markdown link will silently stay unprocessed. Consider adding a check for remaining[...](...)patterns before short-circuiting, or document this trade-off. @copilot please address this.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
[/diagnosing-bugs] The
<askip guard uses/<a[\s>]/ibut the regex pattern string uses'gi'flags, matching case-insensitively — while the guard itself already uses/i. This is fine, but the guard won't catch<A HREF=...>produced by external HTML (capital-A anchor). Both the existing regex and the guard need to be case-insensitive consistently, which they are — just worth a note that/<A[\s>]/iis equivalent and matches both cases.Actually the real concern:
/<a[\s>]/iwill also skip content that contains an<abbr>tag (it matches<abwhich starts with<afollowed by a space... wait,<abbris<a+b— the pattern<a[\s>]requires<afollowed by whitespace or>, so<abbr>won't match). This is actually fine — just confirm the guard is intentional and add a test for<summary>content containing<abbr>to document the behaviour.@copilot please address this.
Uh oh!
There was an error while loading. Please reload this page.