Virtualize and harden native chat timeline

[bkudiess]

Summary

• virtualize the native chat timeline with a WinUI ItemsRepeater host while preserving the existing chat visual design
• split chat timeline/composer internals into clearer UI-focused names and helper files
• harden chat scroll behavior: default to latest on open, preserve intentional scrolled-up position, stabilize follow-bottom/load-earlier behavior
• restore Allow always permission action rendering and AllowedAlways decided badge handling
• render unknown permission action keys explicitly as Action: <key> instead of falling through to Allow
• update the native chat UI proof test for the new VirtualizedChatView/ItemsRepeater path

Validation proof

Validated locally on chat-virtualized-refactor after the latest push:

./build.ps1
  PASS - all projects built (Shared, Cli, WinNodeCli, SetupEngine, WinUI)

dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
  PASS - 2,722 passed, 31 skipped

dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
  PASS - 1,654 passed

dotnet test ./tests/OpenClawTray.FunctionalUI.Tests/OpenClawTray.FunctionalUI.Tests.csproj --no-restore
  PASS - 10 passed

Additional focused proof:

dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore --filter "ChatPermissionRenderingContractTests|OpenClawChatDataProviderTests.RespondToPermissionAsync_AllowAlways|StableRowCollectionTests|ChatToolCallsToggleContractTests|ChatTimelineVirtualizationContractTests"
  PASS - focused permission/virtualization contracts passed

Manual / computer-use proof

• Launched the rebased branch build locally and opened openclaw://chat.
• Computer-use confirmed the OpenClaw Companion Chat surface is visible and targetable.
• Confirmed Chat opens on the latest visible message area with the Scroll-to-latest affordance hidden when already following latest.
• Navigated away to Connection and back to Chat; Chat returned to latest when no intentional scrolled-up offset was saved.
• Verified the branch keeps the existing visual design while the timeline now uses the native VirtualizedChatView host.

UI proof note

• ChatTimelineVirtualizationProofTests was updated to validate the new native VirtualizedChatView/ItemsRepeater path, including the chrome row and native-host realization expectations.
• Local direct UITest execution is blocked on this machine by Windows App SDK dynamic dependency resolution (Package dependency criteria could not be resolved), so CI remains the source of truth for the UITest job.

Notes

• Unrelated WorkspacePage work was kept out of this branch and preserved only in local stashes.

[clawsweeper]

Codex review: found issues before merge. Reviewed July 10, 2026, 1:19 PM ET / 17:19 UTC.

Summary
The PR replaces the existing FunctionalUI virtualized chat timeline with a native WinUI ItemsRepeater host, adds a generic native-control bridge, refactors chat components, and changes scrolling and permission rendering.

Reproducibility: not applicable. as a feature and architecture PR. Current main already virtualizes chat rows, and the PR does not provide a failing current-main scenario demonstrating that the supported path cannot satisfy the requested scale or scrolling behavior.

Review metrics: 3 noteworthy metrics.

• Patch size: 29 files, +1,450/-736. The PR replaces a core rendering path and introduces a reusable native-control API.
• Existing virtualizer: 1 merged production path. Current main already uses an ItemsRepeater-backed timeline with strong runtime and cleanup proof.
• Final unproven delta: 1 file, +20/-4. The latest manual-scroll behavior change has no matching inspectable proof or focused regression test.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until stronger real behavior proof is added.

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

Rank-up moves:

• Resolve whether VirtualizedChatView replaces or is removed in favor of VirtualVStack.
• Provide redacted before-and-after current-main versus PR-head proof for the complete scroll-state and permission matrix.
• [P1] Add focused coverage for appended entries while intentionally scrolled up.

Proof guidance:

• [P1] Needs stronger real behavior proof before merge: The PR body reports manual observations but provides no inspectable current-head screenshot, recording, UI diagnostics, or logs demonstrating the replacement's benefit and final scroll behavior; add redacted evidence, update the PR body to trigger review, or ask a maintainer to comment @clawsweeper re-review.

Risk before merge

• [P1] Merging the generic native host while retaining the existing virtual-stack primitive creates two lifecycle, recycling, and scroll implementations for the same production timeline behavior.
• [P1] The exact-head manual-scroll change is not demonstrated by inspectable real behavior proof, leaving intentional position preservation uncertain.
• [P1] The active changes-requested maintainer review has not been resolved.

Maintainer options:

1. Consolidate before merge (recommended)
   Keep one virtualization implementation, add focused manual-scroll regression coverage, and provide exact-head WinUI proof for the complete scroll and permission matrix.
2. Accept two rendering paths
   Merge both primitives only if maintainers explicitly own the added lifecycle and maintenance burden and document their separate supported use cases.
3. Pause the replacement
   Retain the merged VirtualVStack implementation and close or narrow this PR if no concrete deficiency requires a new native host.

Next step before merge

• [P2] A maintainer must choose the permanent virtualization architecture and require exact-head proof; automation should not decide whether the new generic rendering API belongs.

Maintainer decision needed

• Question: Should native chat replace the established FunctionalUI VirtualVStack implementation with the new generic NativeElement and VirtualizedChatView architecture?
• Rationale: Both implementations virtualize the same production timeline, and source review cannot determine whether maintainers want a second generic rendering boundary or prefer hardening the recently merged supported primitive.
• Likely owner: shanselman — He is the active reviewer and a recent owner of both the timeline and native UI proof surface.
• Options:
  • Harden the existing path (recommended): Port the useful scroll and permission fixes onto VirtualVStack and avoid adding a parallel native-host architecture.
  • Approve the native replacement: Adopt VirtualizedChatView as the single timeline owner, document why VirtualVStack is insufficient, and remove or deprecate the superseded path with focused proof.

Security
Cleared: The patch adds no dependency or workflow execution surface, retains inert Markdown behavior, and explicitly labels unknown permission actions while submitting their original keys.

Review findings

• [P1] Avoid adding a second chat virtualization path — src/OpenClaw.Tray.WinUI/Chat/ChatTimeline.cs:2017-2019

Review details

Best possible solution:

Choose one timeline virtualization owner: either apply the useful scroll and permission hardening to the existing VirtualVStack path, or explicitly approve the native host as its replacement and remove or deprecate the superseded primitive after compatibility and runtime proof.

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

Not applicable as a feature and architecture PR. Current main already virtualizes chat rows, and the PR does not provide a failing current-main scenario demonstrating that the supported path cannot satisfy the requested scale or scrolling behavior.

Is this the best way to solve the issue?

No, not yet. The useful behavior fixes are valuable, but adding a parallel virtualization architecture is not the narrowest maintainable solution unless maintainers explicitly choose it as the replacement.

Full review comments:

• [P1] Avoid adding a second chat virtualization path — src/OpenClaw.Tray.WinUI/Chat/ChatTimeline.cs:2017-2019
  Current main already virtualizes production chat rows through the VirtualVStack and ItemsRepeater path merged in Virtualize chat timeline rows #898, with runtime proof covering recycling, updates, appends, and cleanup. This new NativeElement and VirtualizedChatView route creates competing lifecycle and scroll owners without demonstrating that the supported path is insufficient; please harden the existing primitive or make this an explicitly approved replacement that removes the superseded path. This is a late discovery because the call was unchanged at the prior reviewed SHA.
  Confidence: 0.96
  Late finding: first raised on code an earlier review cycle already covered.

Overall correctness: patch is incorrect
Overall confidence: 0.94

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 8a9e35142d49.

Label changes

Label changes:

• add merge-risk: 🚨 compatibility: The new generic native-control path duplicates and may supersede a recently merged renderer contract used by current chat behavior.
• add rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• remove rating: 🧂 unranked krab: Current PR rating is rating: 🦪 silver shellfish, so this older rating label is no longer current.

Label justifications:

• P2: The PR addresses bounded chat scalability and scrolling improvements but is not an emergency regression.
• merge-risk: 🚨 session-state: Follow, restore, prepend, or manual-scroll errors could move users away from their intended chat position.
• merge-risk: 🚨 compatibility: The new generic native-control path duplicates and may supersede a recently merged renderer contract used by current chat behavior.
• rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
• status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The PR body reports manual observations but provides no inspectable current-head screenshot, recording, UI diagnostics, or logs demonstrating the replacement's benefit and final scroll behavior; add redacted evidence, update the PR body to trigger review, or ask a maintainer to comment @clawsweeper re-review.

Evidence reviewed

What I checked:

• Existing supported virtualization: Merged pull request Virtualize chat timeline rows #898 already moved production chat rows to an ItemsRepeater-backed VirtualVStack, with runtime proof covering 241 variable-height rows, recycling, updates, appended-message following, and renderer cleanup. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, fcc74778a35c)
• Parallel replacement introduced: The proposed timeline creates VirtualizedChatView through a new generic NativeElement boundary instead of using the established FunctionalUI virtual stack. (src/OpenClaw.Tray.WinUI/Chat/ChatTimeline.cs:2017, 0b532dab6aaf)
• Late-finding continuity: The native-host call is unchanged between the previous reviewed SHA and the current head, so the duplicate-path concern was equally visible during the prior review cycle. (src/OpenClaw.Tray.WinUI/Chat/ChatTimeline.cs:2017, 44d292824de8)
• Final-head proof gap: The final commit changes manual-scroll override state, but the PR body provides only narrative observations and no inspectable screenshot, recording, diagnostics, or logs for that exact head. (src/OpenClaw.Tray.WinUI/Chat/Controls/VirtualizedChatView.cs:153, 0b532dab6aaf)
• Active maintainer review: The live PR remains draft with a changes-requested review asking for exact-head runtime proof of open-at-latest, scrolled-up preservation, load-earlier anchoring, streaming follow-bottom, and permission rendering. (0b532dab6aaf)
• Permission safety: Unknown permission actions receive an explicit localized fallback label while the original gateway action key is submitted, and AllowedAlways receives its distinct decided label. (src/OpenClaw.Tray.WinUI/Chat/ChatTimeline.cs, 0b532dab6aaf)

Likely related people:

• shanselman: Introduced the current timeline file incarnation and submitted the active review covering virtualization lifecycle, approval safety, and runtime-proof expectations. (role: reviewer and recent area contributor; confidence: high; commits: 4166e0fd63f8; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, tests/OpenClaw.Tray.UITests/ChatTimelineVirtualizationProofTests.cs)
• TurboTheTurtle: Authored the merged VirtualVStack and ItemsRepeater implementation that this PR proposes to replace. (role: current virtualization introducer; confidence: high; commits: fcc74778a35c; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClawTray.FunctionalUI/FunctionalUI.cs)
• RBrid: Introduced the native FunctionalUI chat experience and later added inline permission approval behavior. (role: native chat feature introducer; confidence: high; commits: 08cab69a038c, 7d9152f427a3; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClawTray.FunctionalUI/FunctionalUI.cs)
• calebeden: Recently maintained timeline render identity and queued-message behavior around the same rendering surface. (role: recent chat rendering contributor; confidence: medium; commits: f89a88a6baf4, c9b5476a873f; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatTimeline.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.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.

Review history (8 earlier review cycles)

• reviewed 2026-07-09T01:54:34.407Z sha a5f40be :: needs changes before merge. :: [P2] Update the native timeline proof assertions
• reviewed 2026-07-09T02:19:32.425Z sha 6ac0da0 :: needs maintainer review before merge. :: none
• reviewed 2026-07-09T15:36:05.723Z sha 570d8ef :: needs maintainer review before merge. :: none
• reviewed 2026-07-09T15:43:31.148Z sha 570d8ef :: needs maintainer review before merge. :: none
• reviewed 2026-07-09T19:37:14.620Z sha 3629e1b :: needs maintainer review before merge. :: none
• reviewed 2026-07-09T23:30:54.417Z sha aee6c67 :: needs maintainer review before merge. :: none
• reviewed 2026-07-10T10:27:01.637Z sha 065f1be :: needs changes before merge. :: [P1] Restore bottom-row realization after fast scrolling
• reviewed 2026-07-10T17:01:25.688Z sha 44d2928 :: needs maintainer review before merge. :: none

[shanselman]

Thanks for pushing this forward — this is a big and valuable direction. Moving the native chat timeline to an ItemsRepeater/VirtualizedChatView path is the right kind of work for long conversations, and I appreciate that the PR keeps the existing visual design while adding tests around row identity, StableRowCollection, permission rendering, and the virtualization proof path.

I did a dual-model adversarial pass plus my own inspection. The broad architecture looks promising, but I do not think this is merge-ready yet. There is one concrete approval-label bug, and the exact-head test job is still pending, which matters a lot for a PR that touches the chat renderer and FunctionalUI native hosting.

Blocking before merge

Unknown permission actions render visually as "Allow"

In ChatTimeline.cs, pending permission actions are normalized and rendered like this:

var label = action switch
{
    ChatPermissionActionKeys.AllowAlways => allowAlwaysLabel,
    ChatPermissionActionKeys.Deny => denyLabel,
    _ => allowLabel,
};

var button = Button(label, () => onResponse?.Invoke(requestId, action))

That means any future/non-standard gateway action key is visually shown to the user as Allow, while the click sends the original unknown action key. Because this UI is a security/approval surface, the label must describe the action being submitted. A user should never click a button labeled "Allow" and actually send an unknown action.

Suggested fix:

• Keep the explicit labels for known actions:
  • allow / allow-once → "Allow once"
  • allow-always → "Always allow"
  • deny → "Deny once" or the existing deny copy
• For unknown actions, render a safe explicit fallback rather than allowLabel. Examples:
  • use a humanized action key: Action: <key>
  • or a localized format: Chat_Permission_ActionFallbackFormat = "Run action: {0}"
• Add a regression test that proves an unknown action key does not render as "Allow" but still invokes the original action key if clicked.

This should block merge.

Exact-head test check is still pending

At review time, gh pr checks 949 still showed the Build and Test test job pending. This PR changes:

• native chat rendering,
• FunctionalUI native host behavior,
• virtualization / realization,
• scroll-to-latest behavior,
• permission rendering,
• and UITest proof expectations.

For this kind of change, the test job is not just routine. It is the primary behavior proof for Tray tests, FunctionalUI tests, and the virtualization UI proof path. Please wait for it to finish green or rerun it if stuck.

Additional validation I would like before merge

Once the blocker above is fixed and CI is green, please include current-head proof for these specific behaviors:

1. Open at latest

   • Open Chat with a non-empty history.
   • Confirm the visible timeline starts at the latest message and the scroll-to-latest affordance is hidden when already following latest.

2. Preserve intentional scrolled-up position

   • Scroll up intentionally.
   • Navigate away and back, or otherwise force a remount if that is part of the intended contract.
   • Confirm the scrolled-up position is preserved when it should be.

3. Load earlier / prepend anchoring

   • Trigger the load-earlier path.
   • Confirm prepended rows do not yank the user to the top or bottom unexpectedly.

4. Follow-bottom during streaming

   • While following latest, stream/update an assistant response.
   • Confirm the viewport follows smoothly and the scroll-to-latest button does not flash or incorrectly appear during programmatic animated scrolling.

5. Permission actions

   • Confirm Allow once, Always allow, and Deny render correctly.
   • Confirm the decided badge for AllowedAlways renders as intended.
   • Include the new unknown-action fallback test mentioned above.

Non-blocking notes

FunctionalUI native host design looks mostly right

The NativeElement/ConfigureNative path appears to respect the existing FunctionalUI mark-and-sweep lifecycle because the native host itself is still created through the normal GetOrCreate<ContentControl>(path) path and therefore gets visited during the eager root render. The virtualization is then inside the hosted native control, and each realized row owns its own host/render path. That is the right pattern for adding virtualization without fighting the renderer's prune model.

Please keep this invariant in mind: lazy/virtualized controls must keep the owner host visited every render, and any realized row host needs an explicit cleanup path. The current direction seems aligned with that.

Re-mounting realized rows on every update may be acceptable but deserves attention

RefreshRealizedRows appears to refresh all realized rows whenever the backing row map changes. Because virtualization bounds the realized set, this is probably okay, and FunctionalUI diffing should make it tolerable. Still, streaming assistant text can update frequently, so please keep an eye on whether token streaming causes visible row churn or unnecessary work.

Source-text tests are useful but not sufficient

Several tests are source-contract tests that assert implementation shape. That is helpful for guarding refactors in WinUI-only seams, but the merge confidence for this PR should come from runtime behavior: FunctionalUI tests, Tray tests, and the UI virtualization proof tests. Please do not treat source-text assertions alone as proof that scrolling/realization behavior works.

Suggested done criteria

I would be comfortable re-reviewing once:

• unknown permission actions no longer render as "Allow";
• a regression test covers that behavior;
• the exact-head test job is green;
• PR proof explicitly covers open-at-latest, scrolled-up preservation, load-earlier anchoring, follow-bottom during streaming, and permission action rendering.

Again, the overall direction is good. I just want to be careful because this PR changes the core chat rendering surface and an approval UI path.

[bkudiess]

Addressed Scott's blocking permission-action feedback: unknown gateway permission actions now render with an explicit localized fallback label (\Action: ) instead of \Allow, while still submitting the original action key. Added contract coverage for the fallback, and full local validation is green (build, Shared, Tray, FunctionalUI).