Fix ChatPage WaitingPanel overlay floating over usable chat (#730)

[RBrid]

Several ChatPage transitions showed the WebView without collapsing the WaitingPanel/RetryChatButton/PlaceholderPanel/ErrorPanel that share its Grid.Row, leaving the "Waiting for chat to start..." overlay visible on top of an already-usable chat.

Extract a pure ChatPagePanelStates helper with an IChatPagePanelHost interface and four named transition helpers (ApplyShowingWebView, ApplyShowingError, ApplyShowingReadinessFailure, ApplyShowingRetryInProgress). Each helper explicitly sets every panel, so adding a new panel cannot silently drift out of sync.

Route all six panel-transition sites through the helpers:

• NavigateWebViewToCurrentChatUrl
• _navCompletedHandler success and failure branches
• NavigateWhenChatReadyAsync
• ShowChatReadinessFailure
• OnRetryChat

The pure helper is cross-compiled into OpenClaw.Tray.Tests and covered by 12 unit tests via a fake IChatPagePanelHost. The WinUI adapter asserts UI-thread affinity in debug builds.

Fixes #730.

Validation (AGENTS.md)

Ran on commit 0334925 (Windows, local worktree):

• ./build.ps1 — ✅ green
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj — ✅ 2130 passed, 29 skipped
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj — ✅ 990 passed (includes 12 new ChatPagePanelStatesTests)

[clawsweeper]

Codex review: needs real behavior proof before merge. Reviewed June 9, 2026, 4:44 PM ET / 20:44 UTC.

Summary
The branch replaces several ChatPage inline panel-visibility assignments with a pure ChatPagePanelStates helper, wires it into tray tests, and adds unit coverage for WebView/error/readiness/retry panel states.

Reproducibility: yes. by source inspection, at medium confidence: current main has WebView-visible transitions that do not consistently collapse peer panels in the same grid row. I did not run a live Windows UI repro in this read-only review.

Review metrics: 2 noteworthy metrics.

• Changed files: 4 files affected. The patch is confined to ChatPage panel logic, a pure helper, tray test project wiring, and new unit tests.
• Regression tests: 12 tests added. The tests cover the pure panel-state helper that owns the stale-overlay regression behavior.

Merge readiness
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🐚 platinum hermit
Result: blocked until real behavior proof from a real setup is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

• [P1] Add a screenshot, recording, terminal/live output, linked artifact, or redacted log showing the real Windows ChatPage after the waiting overlay no longer covers usable chat; redact private endpoints, tokens, IP addresses, account details, and other private data before posting.

Proof guidance:

• [P1] Needs real behavior proof before merge: Only validation/test results are provided; no real Windows ChatPage screenshot, recording, live output, linked artifact, or redacted log shows the after-fix overlay behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Mantis proof suggestion
A visible Windows ChatPage proof would materially help confirm the overlay no longer covers usable chat. A maintainer can ask Mantis to capture proof by posting a new PR comment that starts with the OpenClaw Mantis account mention, followed by:

visual task: verify that the Windows ChatPage becomes usable without the WaitingPanel or Retry overlay remaining on top after chat readiness.

Risk before merge

• [P1] The PR body reports tests but does not include after-fix real Windows ChatPage proof, so the actual WinUI overlay behavior remains unobserved in a real setup.

Maintainer options:

1. Decide the mitigation before merge
   Land this focused panel-state helper after redacted real Windows proof confirms the waiting/retry overlay no longer covers usable chat.
2. Pause or close
   Do not merge this PR until maintainers decide whether the risk is worth taking.

Next step before merge

• [P1] The remaining blocker is contributor/runtime proof plus normal maintainer review, not a narrow repair that automation can supply.

Security
Cleared: The diff changes local ChatPage UI state logic and test compilation only; no concrete security or supply-chain concern is visible.

Review details

Best possible solution:

Land this focused panel-state helper after redacted real Windows proof confirms the waiting/retry overlay no longer covers usable chat.

Do we have a high-confidence way to reproduce the issue?

Yes by source inspection, at medium confidence: current main has WebView-visible transitions that do not consistently collapse peer panels in the same grid row. I did not run a live Windows UI repro in this read-only review.

Is this the best way to solve the issue?

Yes with a proof caveat: centralizing the panel-state transitions is a narrow maintainable fix, and the added unit tests cover the stale-overlay states without changing gateway routing. Real Windows proof is still needed before merge.

AGENTS.md: found and applied where relevant.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 71d249711d63.

Label changes

Label justifications:

• P2: The PR targets a normal-priority Windows ChatPage usability bug with limited blast radius.
• rating: 🧂 unranked krab: Overall readiness is 🧂 unranked krab; proof is 🧂 unranked krab and patch quality is 🐚 platinum hermit.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs real behavior proof before merge: Only validation/test results are provided; no real Windows ChatPage screenshot, recording, live output, linked artifact, or redacted log shows the after-fix overlay behavior. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Repository policy read: AGENTS.md was read fully; its validation guidance affected the review because the PR body reports the required build, shared test, and tray test commands, while this read-only review did not rerun artifact-producing validation. (AGENTS.md:1, 71d249711d63)
• Current main has the stale overlay class: On current main, NavigateWebViewToCurrentChatUrl only collapses ErrorPanel before showing the WebView, leaving other peer panels outside the transition. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:323, 71d249711d63)
• Panels overlap in the same row: ChatHost, WebView, LoadingRing, WaitingPanel, PlaceholderPanel, and ErrorPanel are all in Grid.Row=1, so stale visible panels can cover the usable chat surface. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml:61, 71d249711d63)
• PR centralizes affected transitions: The PR patch routes the WebView-visible, error, readiness-failure, and retry-in-progress transitions through ChatPagePanelStates helpers instead of direct inline visibility assignments. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:327, 03349250999a)
• Regression coverage added: The PR adds ChatPagePanelStatesTests for the stale WaitingPanel/RetryChatButton cases and helper idempotence/null-host behavior. (tests/OpenClaw.Tray.Tests/Pages/ChatPagePanelStatesTests.cs:1, 03349250999a)
• Proof still missing: The PR body reports validation commands, and the only PR comment is the earlier ClawSweeper proof request; no screenshot, recording, live output, linked artifact, or redacted runtime log was posted after the fix. (03349250999a)

Likely related people:

• Mike Harsh: The post-wizard chat handoff commit added the WaitingPanel/RetryChatButton readiness flow that created the relevant panel-state surface. (role: introduced behavior; confidence: high; commits: fd8ff7dad9d4; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml, src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs)
• Christine Yan: Current blame for the ChatPage XAML and most affected visibility/readiness lines points at the localization/code-behind commit that added the current file versions. (role: recent area contributor; confidence: medium; commits: 85445c78066b, 488f26509ced; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml, src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs)
• Régis Brid: Prior merged history shows substantial ChatPage work for the native FunctionalUI chat experience, so this person is relevant to ChatPage surface transitions beyond this PR author role. (role: adjacent chat surface contributor; confidence: medium; commits: 08cab69a038c; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs)

What the crustacean ranks mean

• 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
• 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
• 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
• 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
• 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
• 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
• 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.