[docs] Note Aspire view no longer steals sidebar focus on reload

[aspire-repo-bot]

Documents changes from microsoft/aspire#19754

@ellahathaway

Targeting release/13.6 based on the source PR milestone 13.6.

Why

The source PR fixes a bug where reloading VS Code while another sidebar view (e.g. Explorer) was active could cause the Aspire view to steal focus and reveal a previously hidden Activity Bar icon. This is a user-visible behavior change (the PR body includes an explicit "User-facing behavior" section), so it needs to be reflected in the extension docs.

What changed

• Added a note under The Aspire view section in get-started/aspire-vscode-extension.mdx explaining that single-AppHost auto-expansion is preserved, but the view no longer auto-activates/reveals itself in the Activity Bar unless the user explicitly opens it.

Files modified

• src/frontend/src/content/docs/get-started/aspire-vscode-extension.mdx

No new pages were created; this updates the existing VS Code extension page.

Generated by PR Documentation Check for #19754 · auto · 39.4 AIC · ⌖ 6.91 AIC · ⊞ 19.7K · ◷

[aspire-repo-bot]

Frontend HTML artifact ready

The latest frontend build uploaded the frontend-dist artifact for PR #1598. Use the VS Code button below to open this PR with GitHub Artifacts Explorer and browse the built HTML locally.

This comment updates automatically when a new frontend build artifact is uploaded.

[David Pine (IEvangelist)]

Automated docs-accuracy review

Source of truth: microsoft/aspire @ main (HEAD 1cdf7d17248ae78ee018abbc314f772ace5e624d).

⚠️ Branch note (non-blocking): This PR targets release/13.6, which does not exist in microsoft/aspire. The source change (microsoft/aspire#19754, "Avoid activating Aspire view during AppHost discovery", merge 1410c1a7fc, fixes issue #19746) is merged on main but not yet in a GA release (latest tag v13.5.3; no v13.6 tag). I verified both claims against upstream/main. Re-confirm against release/13.6 if that branch is later cut.

Phase A — claims: 2 non-narrative claims extracted → ✅ 2 verified, 0 verified-with-nuance, 0 unverifiable, 0 contradicted.
Phase B — doc-tester: 1 route exercised (/get-started/aspire-vscode-extension/) → 0 critical, 0 warnings; 1 knowledge gap (local build predates PR — mitigated).

The note precisely tracks the fix: single-AppHost auto-expansion is preserved, but TreeView.reveal() is now gated on the view being visible so discovery during activation can't steal sidebar focus.

---

Phase A — Claim verification

No contradicted or unverifiable claims, so there are no inline blocking comments. All evidence is below for audit.

✅ 2 verified claims (click to expand)

id	claim	evidence (microsoft/aspire @ main)
V1	When a workspace has exactly one AppHost, the Aspire view auto-expands it — but only once the user explicitly opens the Aspire view	extension/src/views/AspireAppHostTreeProvider.ts — _autoExpandSingleWorkspaceAppHost() guards on if (!this._treeView?.visible || this._repository.viewMode !== 'workspace') return; then if (rootElements.length !== 1 || !(rootElements[0] instanceof WorkspaceAppHostItem)) return; then this._treeView.reveal(appHostItem, { expand: true }). setTreeView subscribes treeView.onDidChangeVisibility(event => { if (event.visible) this._autoExpandSingleWorkspaceAppHost(); }), so auto-expand fires when the view becomes visible (user opens it).
V2	Reloading the window (Developer: Reload Window) while another sidebar view (e.g. Explorer) is active no longer switches focus to Aspire or reveals a hidden Aspire Activity Bar icon	Merge 1410c1a7fc changed the guard from !this._treeView to !this._treeView?.visible, with the comment: "TreeView.reveal() activates a hidden view container. Only reveal after the user opens Aspire so discovery during activation cannot steal sidebar focus." (links issue #19746). Commit title: "Avoid activating Aspire view during AppHost discovery." When the view isn't visible (another sidebar active on reload), reveal() is skipped → no focus steal, no hidden-icon reveal. Regression tests added in extension/src/test/appHostTreeView.test.ts and extension/src/test-e2e/appHostTree.e2e.test.ts.

---

Phase B — Doc-tester results

Playwright-only run against the local docs frontend; no microsoft/aspire source was consulted in this phase.

Route exercised: /get-started/aspire-vscode-extension/

Category	Passed	Failed	Warnings
Page health (HTTP/console)	1	0	0
Reused component rendering	1	0	0
Insertion-region integrity	1	0	0

Critical issues: none.
Warnings: none (from a blind-user perspective).

Passed checks

• /get-started/aspire-vscode-extension/ — HTTP 200, title "Aspire Visual Studio Code extension | Aspire". 0 console errors, 0 warnings.
• Reused component renders: the new content is a single :::note[Single-AppHost auto-expansion] admonition — the same Starlight note component already renders twice on this page (Renamed polling setting and Debugging notes). The PR introduces no new component types.
• Insertion region intact: the new note is inserted after the "Renamed polling setting" note (under the "The Aspire view" H2) and before the "## Run, debug, and deploy" H2 — all three neighbors render.

Knowledge gap — local docs build predates this PR: The served HTML contains neither the "Single-AppHost auto-expansion" note title nor the string "Reload Window", so I could not exercise the new note directly as a blind user. Mitigation: validated page health, confirmed the note admonition component already renders on this page, confirmed the insertion point is intact, and confirmed the note adds no new internal links. Test-environment limitation, not a documentation defect.

---

Verdict: APPROVE

Both non-narrative claims are verified against microsoft/aspire @ main (source PR #19754 is merged): single-AppHost auto-expansion is preserved and reveal is gated on view visibility exactly as the note describes, and the doc-tester run found no critical issues or warnings. The only caveat is the informational branch-name mismatch (release/13.6 not present in microsoft/aspire); re-confirm against that branch if/when it is cut.

_{🤖 Automated Phase A (source-of-truth claims) + Phase B (doc-tester) review. Phase A read microsoft/aspire @ main; Phase B used Playwright against the local docs site only.}