Main Chat page keeps first-chat startup overlay after chat is already usable

[sorry123luck]

Summary

The main Windows Companion Chat page can keep showing the first-chat startup/loading overlay even after chat is already usable and messages are being sent/received.

The Tray mini chat window does not show the same stuck overlay, which suggests the Gateway/chat backend is ready and this is a main Chat page UI state issue.

Environment

• OpenClaw Windows Companion: v2026.6.1
• Gateway: OpenClaw v2026.6.1, running locally in WSL
• Gateway URL: ws://127.0.0.1:18789
• Windows user: Administrator

What happened

On the main Chat page, the UI kept showing a centered startup overlay/spinner with text like:

等待聊天启动...
聊天已准备就绪；正在启动您的首次对话...

At the same time, chat was already usable:

• the composer was visible,
• messages could be sent,
• assistant replies were visible,
• tool activity could run,
• the Tray mini chat window showed the same conversation without the stuck startup overlay.

Expected behavior

Once the chat compose target is ready and the conversation is usable, the first-chat startup overlay should disappear.

The loading/startup state should be cleared when the main Chat page has enough state to render an active conversation.

Actual behavior

The main Chat page continues to render the startup overlay on top of an already active conversation.

This makes the UI look stuck even though chat is functioning.

Related prior work

This may be related to #498, which changed chat startup/reconnect loading UI and welcome-state gating.

It may also be adjacent to #457, which touched zero-state chat behavior and main / agent:main:main session handling.

Suggested fix

• Clear the first-chat startup overlay when compose is ready and a real active timeline/message exists.
• Make the main Chat page and Tray mini chat use the same readiness condition if possible.
• Add a regression test for the case where chat is usable but the startup overlay would otherwise remain visible.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed June 9, 2026, 1:41 AM ET / 05:41 UTC.

Summary
Keep open: current main still has ChatPage WebView visibility paths that can show a usable chat surface without clearing the matching startup WaitingPanel, so the reported UI-state problem is not solved.

Reproducibility: yes. by source inspection: the reported text is owned by ChatPage WaitingPanel, and current WebView display paths can leave that panel visible after the WebView is shown. I did not run a live Windows UI repro.

Next step
The remaining work is a narrow ChatPage WebView visibility-state fix with clear likely files and validation commands.

Review details

Best possible solution:

Clear the main ChatPage WaitingPanel on every WebView-visible/success path and cover the already-initialized navigation path with a focused regression test.

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

Yes by source inspection: the reported text is owned by ChatPage WaitingPanel, and current WebView display paths can leave that panel visible after the WebView is shown. I did not run a live Windows UI repro.

Is this the best way to solve the issue?

Yes: the narrow maintainable fix is to clear WaitingPanel anywhere ChatPage shows or successfully navigates the WebView, without changing gateway readiness or native tray chat behavior.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• No live Windows UI reproduction was run in this read-only review, so the exact user trigger should be confirmed while fixing.

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

Label changes

Label changes:

• add P2: The report describes a real chat usability bug with limited blast radius because chat still functions but the main page looks stuck.
• add impact:other: The issue affects main chat page usability/loading-state presentation, outside the more specific owned impact categories.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P2: The report describes a real chat usability bug with limited blast radius because chat still functions but the main page looks stuck.
• impact:other: The issue affects main chat page usability/loading-state presentation, outside the more specific owned impact categories.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore

What I checked:

• Reported overlay matches ChatPage waiting UI: The main ChatPage XAML defines a WaitingPanel after the WebView in the same Grid, and the localized resources contain the reported waiting/ready text. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml:71, 71d249711d63)
• Navigation success shows WebView but does not clear WaitingPanel: InitializeWebViewAsync sets WaitingPanel.Visibility = Visible; the success handler later collapses ErrorPanel and shows WebView, but does not collapse WaitingPanel in that success branch. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:409, 71d249711d63)
• Already-initialized WebView path can preserve stale waiting UI: NavigateWebViewToCurrentChatUrl only collapses ErrorPanel before showing/navigating the WebView, so a previously visible WaitingPanel can remain over an active WebView. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:323, 85445c78066b)
• Readiness path clears the panel only in one path: NavigateWhenChatReadyAsync changes the status to ChatPage_ChatReady, waits for onboarding bootstrap, and collapses WaitingPanel only immediately before one direct WebView navigation path. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:499, 85445c78066b)
• Tray mini chat is structurally different: The tray ChatWindow WebView path uses a loading ring and success handler without the main ChatPage WaitingPanel, matching the report that the tray mini chat does not show the same stuck overlay. (src/OpenClaw.Tray.WinUI/Windows/ChatWindow.xaml.cs:371, 71d249711d63)
• Current main has not fixed the ChatPage overlay path: The diff from latest release tag v0.6.3 to current HEAD only adds comments/localization in ChatPage-related files; it does not add a WaitingPanel clear on the WebView success/reuse paths. (src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs:513, 71d249711d63)

Likely related people:

• Christine Yan: Blame on the WaitingPanel WebView initialization, navigation success, and ready-navigation blocks points to commit 85445c7. (role: introduced current ChatPage waiting surface; confidence: high; commits: 85445c78066b; files: src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml.cs, src/OpenClaw.Tray.WinUI/Pages/ChatPage.xaml, src/OpenClaw.Tray.WinUI/Strings/en-us/Resources.resw)
• kenehong: The issue explicitly points to the merged chat startup/reconnect loading work, and local history shows kenehong authored the skeleton timeline/composer change in commit 20eb9e4. (role: adjacent chat loading UI contributor; confidence: medium; commits: 20eb9e4def56, 758d00ec2ce0; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs)
• Ranjesh: The issue also points to zero-state chat readiness work, and local history shows Ranjesh on the merged zero-state/chat compose-target fix and later chat provider maintenance. (role: adjacent chat readiness contributor; confidence: medium; commits: 7747e6075052, 9a3a7a6131a8, 3d26594b4448; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Connection/ChatNavigationReadiness.cs)

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.

[github-actions]

🤖 This is an automated response from Repo Assist.

Root cause (code-level)

There are two paths where ChatPage shows the WebView without collapsing WaitingPanel:

Path 1 — NavigateWebViewToCurrentChatUrl() (line ~323)
Called when the WebView is already initialised (e.g. user navigates away and back to the Chat page). It hides ErrorPanel and shows the WebView, but never touches WaitingPanel:

private bool NavigateWebViewToCurrentChatUrl()
{
    if (string.IsNullOrEmpty(_chatUrl) || WebView.CoreWebView2 is null)
        return false;
    ErrorPanel.Visibility = Visibility.Collapsed;
    WebView.Visibility = Visibility.Visible;          // WaitingPanel left as-is
    WebView.CoreWebView2.Navigate(_chatUrl);
    return true;
}

Path 2 — _navCompletedHandler success branch (line ~425)
The navigation-completed handler collapses ErrorPanel and shows WebView on success, but again leaves WaitingPanel untouched:

if (e.IsSuccess)
{
    ErrorPanel.Visibility = Visibility.Collapsed;
    WebView.Visibility = Visibility.Visible;          // WaitingPanel left as-is
}

The WaitingPanel is only properly collapsed inside NavigateWhenChatReadyAsync, which is the first-navigate flow. Subsequent navigations skip that path.

Minimal fix

Add WaitingPanel.Visibility = Visibility.Collapsed; in both places above. The Tray mini-chat window (ChatWindow.xaml.cs) uses a LoadingRing pattern without a WaitingPanel, which is why it doesn't exhibit the same stuck-overlay behaviour.

Generated by 🌈 Repo Assist, see workflow run. Learn more.

Add this agentic workflows to your repo

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@97143ac59cb3a13ef2a77581f929f06719c7402a