fix(web): keep newer titles when an untouched header rename ends#23188

Problem

An untouched rename in the chat header can overwrite a newer thread title. Start renaming "New thread", rename the same thread to "Fix login redirect" in another client, then click away without typing. The first client restores "New thread". Enter has the same result.

The input keeps the title captured when editing began, but the commit handler compares it with the latest title. A concurrent update turns an untouched edit into a stale write. Automatic titling can produce the same sequence.

Change

Compare the submitted title with renamingTitle, the baseline already captured for the rename session. Keep the existing activeThreadTitle fallback. An untouched edit becomes a no-op; an intentional edit still saves.

Add one deterministic browser regression covering blur and Enter, plus an intentional-edit control after a concurrent update. It checks persisted title behavior without timers, frame waits or mock-call assertions.

Scope and approval

This qualifies for CONTRIBUTING.md's small, focused obvious-bug exception without a prior issue. The change reuses existing state in the header's commit handler. Web and desktop share this header; mobile uses a separate implementation. The sidebar rename editors (SidebarThreadRow and LegacySidebar) compare against the live title the same way. They keep the typed value in state with no captured baseline, so they need their own change and are not touched here.

Verification

pnpm exec vp test run src/components/chat/ChatHeader.browser.test.tsx --project browser, from apps/web: the same regression fails both cases against the base component with expected "Fix login redirect", received "New thread". Both cases pass with the candidate, including the genuine-edit control.

pnpm exec vp lint apps/web --report-unused-disable-directives, changed-file pnpm exec vp fmt --check, and pnpm --filter @t3tools/web typecheck passed. Package lint reported existing warnings outside the changed files. git diff --check passed.

Focused regression output, failing on base and passing on the candidate.

Browser regression fails on base and passes on candidate

Production builds used local commits e64766c56a (base) and cc9cf576e9 (candidate), whose ChatHeader.tsx and regression test are byte-identical to this branch's base and head.

Two real browser clients opened each build on macOS. Client 1 opened the title editor. Client 2 renamed that thread through the UI. Backend reads confirmed the update before client 1 blurred or pressed Enter. Base overwrote the newer title on both paths. Candidate retained it with the same backend update timestamp. An intentional edit propagated to client 2. No provider run was needed. Services, tabs and disposable state were cleaned up.

Base, after the concurrent update: the sidebar shows the newer title while the input still holds its captured value.

Base editor before blur

Base, after blur: the stale title returns.

Base loses the concurrent title

Candidate, after the same update and blur: the newer title survives.

Candidate preserves the concurrent title

Enter shows the same before/after difference.

Base loses the title on Enter

Candidate preserves the title on Enter

Not checked:

• Native desktop shell, Linux production browser, mobile clients and the two sidebar rename editors (unchanged).
• Provider-driven automatic titling; the two-client flow exercises the same concurrent metadata update.
• Broad repository tests and candidate CI. The branch merges cleanly with current main.

Prior PRs: #11830 by Julius Marminge added the current header editor. #7817 by Utkarsh Patil introduced double-click rename. Utkarsh's closed #7822 fixed a stale-title flash after an intentional rename, a different bug; this PR reuses none of it. Nearby #21444 by Matt Stone and #22352 by Mantas Kantautas change separate menu actions. No same-fix proposal was found.

Generated with GPT-6.1 Sol in T3 Code Nightly