Fix: TagHelperContext.AllAttributes missing attributes after Razor comment

[Copilot]

Fix: TagHelperContext.AllAttributes missing attributes after Razor comment

Problem Analysis

When a Razor comment (@* *@) appears in an element's attribute list, any attributes after it are missing from TagHelperContext.AllAttributes.

The root cause was in TagHelperBlockRewriter.cs:

1. When iterating through startTag.Attributes, whitespace between attributes is represented as standalone MarkupTextLiteralSyntax nodes
2. These didn't match any known attribute types, causing result = null
3. This triggered error handling that broke the loop and added all remaining attributes as-is
4. RazorCommentBlockSyntax nodes also didn't match, causing the same issue

Solution

Added explicit handling for:

1. RazorCommentBlockSyntax - preserved in syntax tree while continuing to process subsequent attributes
2. MarkupTextLiteralSyntax with whitespace-only content - preserved while continuing processing

else if (child is RazorCommentBlockSyntax razorComment)
{
    attributeBuilder.Add(razorComment);
    continue;
}
else if (child is MarkupTextLiteralSyntax textLiteral)
{
    var content = textLiteral.GetContent();
    if (string.IsNullOrWhiteSpace(content))
    {
        attributeBuilder.Add(textLiteral);
        continue;
    }
    result = null;
}

Testing

Added comprehensive test coverage:

• Single attribute after Razor comment (TagHelperBlockRewriterTest)
• Multiple attributes after a single comment
• Multiple interleaved comments and attributes
• Minimized/boolean attributes after comments
• Parser-level verification of attribute parsing (HtmlAttributeTest)
• Code generation test with bound attributes after Razor comment (CodeGenerationIntegrationTest)

All existing tests pass with no regressions (3,871 compiler tests pass).

Impact

TagHelpers now correctly receive all attributes in their execution context, regardless of Razor comment or whitespace placement. Both bound and unbound attributes after comments are properly processed and included in the generated code.

Original prompt

Issue: #12261

Summary
TagHelperContext.AllAttributes is missing attributes that appear after a Razor comment (@* *@) inside an element's attribute list. When a Razor (server-side) comment is present between attributes, any subsequent attributes are omitted from the TagHelper execution context, leading to incorrect TagHelper behavior.

Reproduction
Given a TagHelper targeting the

tag (or any element processed by a TagHelper):

Input Razor:

<p
  attribute-1="true"
  @* visible *@
  not-visible>
</p>

In the TagHelper's Process/ProcessAsync method, examining context.AllAttributes results in a collection containing only attribute-1, excluding not-visible.

Expected Behavior
All valid attributes appearing after a Razor comment inside a tag's attribute list should be present in TagHelperContext.AllAttributes. Razor comments should be ignored by the attribute collection logic rather than terminating or truncating collection.

Actual Behavior
Attributes that appear after a Razor comment block inside the start tag are missing from TagHelperContext.AllAttributes.

Impact
This breaks TagHelpers that rely on full attribute enumeration (e.g., diagnostic, conditional logic, passthrough attribute processing). It creates surprising behavior for developers who use Razor comments to temporarily disable or annotate attributes.

Suspected Cause
During the parsing / rewriting phase that builds the intermediate node structure for TagHelper execution, encountering a RazorComment (RazorCommentBlockSyntax) inside the attribute list likely causes:

1. Attribute rewriter / binder to stop scanning further attributes, OR
2. The subsequent markup tokens to be treated as plain text rather than attribute name/value pairs, OR
3. A filtering step (e.g., when building the TagHelperExecutionContext / TagHelperAttributeList) to skip tokens following a comment because of an early-exit condition.

Likely Areas to Inspect (filenames approximate; adjust to actual paths):

• Parser: Razor.Parser / MarkupElementRewriter or equivalent
• TagHelper rewriting: TagHelperParseTreeRewriter, TagHelperBlockRewriter
• Intermediate node lowering: TagHelperDocumentClassifierPass, TagHelperComponentTagHelperIntermediateNodePass
• Attribute gathering: DefaultTagHelperDescriptorFactory, TagHelperAttributeTracker, TagHelperExecutionContext / TagHelperAttributeList
• Handling of RazorCommentBlockSyntax within a MarkupStartTagSyntax node

Proposed Fix

1. Update the attribute collection logic to treat Razor comments as transparent (skip them but continue collecting subsequent attributes).
2. Ensure no early return or state corruption occurs when a RazorCommentBlockSyntax is encountered within a start tag's attribute sequence.
3. Add or adjust logic in the parser / rewriter so that tokens following a Razor comment are still tokenized as attributes.
4. Add unit and integration tests verifying that attributes after a Razor comment appear in AllAttributes.

Testing Strategy
Add at least the following tests (adjust namespaces to existing test layout):

• Parser / Syntax: A test that a MarkupStartTagSyntax containing an intervening RazorCommentBlockSyntax still contains the subsequent attribute nodes.
• TagHelper execution: Create a simple TagHelper (e.g., TestTagHelper) and feed Razor with a commented attribute in the middle; assert context.AllAttributes includes all non-comment attributes in order.
• Additional variations:
  a. Multiple attributes after a comment.
  b. Multiple comments interleaved.
  c. Self-closing tag scenario: <p attribute-1="true" @* c *@ attribute-2 />
  d. Minimized attributes (boolean) after a comment.

Acceptance Criteria

• The supplied reproduction case passes: attribute not-visible is present in context.AllAttributes.
• No regression for existing TagHelper attribute parsing (run full test suite).
• Comments do not appear as attributes and do not alter ordering of remaining attributes.
• Works for self-closing and normal start tags.

Non-Goals

• Changing how HTML comments () behave.
• Changing Razor comment semantic model outside of start tag attribute lists.

Implementation Notes
If the parser currently builds a single token list for the start tag, ensure the enumerator that converts tokens to attributes skips RazorComment tokens rather than resetting or bailing. If attribute rewriter uses state machine, add a branch for comment start that preserves the current attribute parsing state and resumes afterwards.

Documentation / Changelog
Add a short entry (if project maintains one) noting: Fixed an issue where attributes appearing after a Razor comment inside a start tag were not included in TagHelperContext.AllAttributes.

Follow Project Contribution Guidelines
Apply coding style, run code formatter, and ensure added tests follow naming conventions. Reference the linked issue in the commit message (e.g., Fixes #12261).

Deliverables

• Code fix in parser / rewriter / lowering layer.
• New o...

This pull request was created as a result of the following prompt from Copilot chat.

Issue: #12261

Summary
TagHelperContext.AllAttributes is missing attributes that appear after a Razor comment (@* *@) inside an element's attribute list. When a Razor (server-side) comment is present between attributes, any subsequent attributes are omitted from the TagHelper execution context, leading to incorrect TagHelper behavior.

Reproduction
Given a TagHelper targeting the

tag (or any element processed by a TagHelper):

Input Razor:

<p
  attribute-1="true"
  @* visible *@
  not-visible>
</p>

In the TagHelper's Process/ProcessAsync method, examining context.AllAttributes results in a collection containing only attribute-1, excluding not-visible.

Expected Behavior
All valid attributes appearing after a Razor comment inside a tag's attribute list should be present in TagHelperContext.AllAttributes. Razor comments should be ignored by the attribute collection logic rather than terminating or truncating collection.

Actual Behavior
Attributes that appear after a Razor comment block inside the start tag are missing from TagHelperContext.AllAttributes.

Impact
This breaks TagHelpers that rely on full attribute enumeration (e.g., diagnostic, conditional logic, passthrough attribute processing). It creates surprising behavior for developers who use Razor comments to temporarily disable or annotate attributes.

Suspected Cause
During the parsing / rewriting phase that builds the intermediate node structure for TagHelper execution, encountering a RazorComment (RazorCommentBlockSyntax) inside the attribute list likely causes:

1. Attribute rewriter / binder to stop scanning further attributes, OR
2. The subsequent markup tokens to be treated as plain text rather than attribute name/value pairs, OR
3. A filtering step (e.g., when building the TagHelperExecutionContext / TagHelperAttributeList) to skip tokens following a comment because of an early-exit condition.

Likely Areas to Inspect (filenames approximate; adjust to actual paths):

• Parser: Razor.Parser / MarkupElementRewriter or equivalent
• TagHelper rewriting: TagHelperParseTreeRewriter, TagHelperBlockRewriter
• Intermediate node lowering: TagHelperDocumentClassifierPass, TagHelperComponentTagHelperIntermediateNodePass
• Attribute gathering: DefaultTagHelperDescriptorFactory, TagHelperAttributeTracker, TagHelperExecutionContext / TagHelperAttributeList
• Handling of RazorCommentBlockSyntax within a MarkupStartTagSyntax node

Proposed Fix

1. Update the attribute collection logic to treat Razor comments as transparent (skip them but continue collecting subsequent attributes).
2. Ensure no early return or state corruption occurs when a RazorCommentBlockSyntax is encountered within a start tag's attribute sequence.
3. Add or adjust logic in the parser / rewriter so that tokens following a Razor comment are still tokenized as attributes.
4. Add unit and integration tests verifying that attributes after a Razor comment appear in AllAttributes.

Testing Strategy
Add at least the following tests (adjust namespaces to existing test layout):

• Parser / Syntax: A test that a MarkupStartTagSyntax containing an intervening RazorCommentBlockSyntax still contains the subsequent attribute nodes.
• TagHelper execution: Create a simple TagHelper (e.g., TestTagHelper) and feed Razor with a commented attribute in the middle; assert context.AllAttributes includes all non-comment attributes in order.
• Additional variations:
  a. Multiple attributes after a comment.
  b. Multiple comments interleaved.
  c. Self-closing tag scenario: <p attribute-1="true" @* c *@ attribute-2 />
  d. Minimized attributes (boolean) after a comment.

Acceptance Criteria

• The supplied reproduction case passes: attribute not-visible is present in context.AllAttributes.
• No regression for existing TagHelper attribute parsing (run full test suite).
• Comments do not appear as attributes and do not alter ordering of remaining attributes.
• Works for self-closing and normal start tags.

Non-Goals

• Changing how HTML comments () behave.
• Changing Razor comment semantic model outside of start tag attribute lists.

Implementation Notes
If the parser currently builds a single token list for the start tag, ensure the enumerator that converts tokens to attributes skips RazorComment tokens rather than resetting or bailing. If attribute rewriter uses state machine, add a branch for comment start that preserves the current attribute parsing state and resumes afterwards.

Documentation / Changelog
Add a short entry (if project maintains one) noting: Fixed an issue where attributes appearing after a Razor comment inside a start tag were not included in TagHelperContext.AllAttributes.

Follow Project Contribution Guidelines
Apply coding style, run code formatter, and ensure added tests follow naming conventions. Reference the linked issue in the commit message (e.g., Fixes #12261).

Deliverables

• Code fix in parser / rewriter / lowering layer.
• New or updated tests covering the scenarios above.
• Optional: doc / changelog note if required by repository contribution practices.

Please proceed to implement the fix accordingly.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[davidwengier]

@copilot Looks great so far, but would be good to see some tests that have the generated C# baselines too. Please add a test for the scenario of having a comment between two bound tag helper attributes in CodeGenerationIntegrationTest.cs as well. Perhaps the "SimpleTagHelpers" test there would be a good example.

[Copilot]

@copilot Looks great so far, but would be good to see some tests that have the generated C# baselines too. Please add a test for the scenario of having a comment between two bound tag helper attribute...

Added TagHelpersWithBoundAttributesAndRazorComment test in CodeGenerationIntegrationTest.cs that verifies both bound attributes are correctly processed when separated by a Razor comment. The generated C# code now includes both value and bound attribute assignments. Also fixed the underlying issue where whitespace MarkupTextLiteral nodes were causing early loop termination. Commit: 802cd85 (initial test) and the latest commit with the complete fix.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

• 0t3vsblobprodcus362.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• 1oavsblobprodcus350.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• 4vyvsblobprodcus361.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• 4zjvsblobprodcus390.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• 51yvsblobprodcus36.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• 96bvsblobprodcus338.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• c50vsblobprodcus330.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• c78vsblobprodcus322.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• kmuvsblobprodcus389.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• l49vsblobprodcus358.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• pdfvsblobprodcus380.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• s8mvsblobprodcus38.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)
• sqdvsblobprodcus333.vsblob.vsassets.io
  • Triggering command: dotnet build src/Compiler/Microsoft.AspNetCore.Razor.Language/test/Microsoft.AspNetCore.Razor.Language.Test.csproj (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

• Configure Actions setup steps to set up my environment, which run before the firewall is enabled
• Add the appropriate URLs or hosts to the custom allowlist in this repository's Copilot coding agent settings (admins only)