[karmegams02]

Description

The default Blazor Web App uses a static HeadOutlet with an interactive
PageTitle on pages such as Counter. The section render-mode diagnostic
therefore reports a warning during prerendering even though the constant title
is rendered correctly and the page becomes interactive normally.

The warning identifies the built-in section as System.Object, which does not
help users determine that the mismatch comes from PageTitle and HeadOutlet.

This change makes the built-in head-section diagnostics actionable and avoids
emitting a Warning for the expected default-template configuration. A
PageTitle mismatch with a static HeadOutlet is logged at Debug instead.
Other section render-mode mismatches continue to log at Warning.

---

Root Cause

HeadOutlet uses internal object instances as the identifiers for its title and
head-content sections. When SectionRegistry reports a render-mode mismatch,
formatting one of these identifiers produces System.Object rather than the
names of the participating components.

In the default per-page interactivity template:

1. HeadOutlet is rendered in the static component tree.
2. The Counter page and its PageTitle use an interactive render mode.
3. Prerendering connects the title content to the static outlet and displays the
   expected title.
4. The render-mode mismatch diagnostic still logs at Warning because the static
   outlet and interactive title cannot exchange subsequent interactive updates.

For the template's constant page title, this warning is noisy and suggests that
the page is broken even though the title and page interactivity work as
expected.

---

Output

Before

The default Counter page emits:

warn: Microsoft.AspNetCore.Components.Sections.SectionRegistry[1]
      The section with ID 'System.Object' has its SectionOutlet in render mode
      'static server-side rendering' and its SectionContent in render mode
      'InteractiveServerRenderMode'.

After

The default static HeadOutlet and interactive PageTitle mismatch is logged
at Debug, so it no longer produces a warning under the default logging
configuration.

When the diagnostic is enabled, it identifies the section as
PageTitle/HeadOutlet and explains that prerendered content may appear
correctly while subsequent interactive updates cannot cross the render-mode
boundary.

Warnings remain enabled for mismatches where suppressing the warning could hide
unexpected behavior, including HeadContent, user-defined sections, and a
static PageTitle paired with an interactive HeadOutlet.

---

Fix Details

File	Change
src/Components/Components/src/Sections/SectionRegistry.cs	Introduce descriptive built-in section identifiers, select the mismatch log level based on the section and outlet render mode, and make the diagnostic guidance more actionable.
src/Components/Web/src/Head/HeadOutlet.cs	Identify the built-in sections as PageTitle/HeadOutlet and HeadContent/HeadOutlet.
src/Components/Endpoints/test/EndpointHtmlRendererTest.cs	Cover PageTitle and HeadContent mismatches across Interactive Server, WebAssembly, and Auto render modes and both component discovery orders.
docs/BlazorComponentsGuidance.md	Document the diagnostic behavior and the limitation around detecting titles that require interactive updates.

---

Tests

EndpointHtmlRendererTest covers the following scenarios for Interactive
Server, Interactive WebAssembly, and Interactive Auto render modes, with both
outlet-first and content-first rendering:

• A static HeadOutlet with an interactive PageTitle logs at Debug.
• A static HeadOutlet with interactive HeadContent continues to log at
  Warning.
• An interactive HeadOutlet with a static PageTitle continues to log at
  Warning.
• A HeadOutlet and PageTitle using the same render mode do not log a
  mismatch.
• The prerendered title or head content is still present in the rendered HTML.
• The diagnostic uses the descriptive built-in section identifier and includes
  actionable guidance.

Test Output

---

Notes

• This change does not enable sections to connect across render-mode
  boundaries.
• Interactive title updates still require PageTitle and HeadOutlet to use
  compatible render modes.
• The Debug exception applies to all PageTitle content paired with a static
  HeadOutlet. The section registry cannot currently distinguish a constant
  title from one that will be updated after the page becomes interactive.
• Detecting lost interactive title updates without warning for unchanged
  default-template titles remains a follow-up problem.
• HeadContent and user-defined section mismatches are intentionally not
  suppressed.

Fixes #69673

[dotnet-policy-service]

Thanks for your PR, @karmegams02. Someone from the team will get assigned to your PR shortly and we'll get it reviewed.

[Copilot]

🟡 Changes recommended

The warning’s static-rendering remediation is incorrect for interactive-outlet/static-content mismatches.

1 open finding

• Make static rendering guidance symmetric for outlet and content · New

What changed in this PR

Improves Blazor head-section mismatch diagnostics and suppresses the expected default-template PageTitle warning.

Changes:

• Adds descriptive built-in section identifiers.
• Demotes static-outlet/interactive-title mismatches to Debug.
• Adds render-mode coverage and documents the behavior.

File	Description
SectionRegistry.cs	Selects diagnostic severity and updates guidance.
HeadOutlet.cs	Adds descriptive head-section identifiers.
EndpointHtmlRendererTest.cs	Tests diagnostic behavior across render modes.
BlazorComponentsGuidance.md	Documents the diagnostic policy and limitation.

🧠 Review effort: Balanced

---

💡 Add a code-review agent skill for context-aware, tailored reviews. Learn more in the docs.

[dariatiurina]

From what I see, this just downgrades this particular warning to Debug when PageTitle is used with a static HeadOutlet. It doesn't fix the problem; it hides the problem in the templates. In a globally interactive app, I can change PageTitle at runtime, and the tab title will update (e.g. developers use a “Please return to the page!” notification). With per-page interactivity and a static HeadOutlet, this will not work. The warning explains why. So the solution should lie in changing the templates or improving the warning instead of just hiding it.