You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(composer): show the autosave copy, and drop a posted draft (#279)
* fix(composer): give the new-thread form the autosave copy it reads
The new-thread page built its copy record without the six keys
ComposerRecovery reads, so the island rendered them as themselves —
"composer.autosave.saved" under the message box the moment a draft
saved. The reply form's record carried them; the new-thread form's
never had.
Both records share one list now, and a test scans the composer
components for the keys they read from the prop so a record cannot fall
behind one again.
Closes#275
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AZGWFg83tyN4hSR3wsPLhF
* fix(composer): drop a posted draft instead of offering it on the next thread
Posting cleared the server draft but two paths put it back, so starting
another thread in the forum offered the one just posted. A Server
Action's redirect is a client-side navigation when scripting is on, so
the browser's own recovery copy was never removed on the one path that
mattered; and the blur that pressing Post fires raced an autosave in
behind the action's own draft removal, recreating the server draft after
it had gone.
The browser copy is now removed when the composer unmounts mid-submit —
what a successful post looks like from the browser — and a pointerdown on
any submit button holds off the blur autosave until the next keystroke,
so the post's draft removal is the last word. Typing after a failed
submit clears the hold, so an attempt that errored still keeps its draft.
Refs #275
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AZGWFg83tyN4hSR3wsPLhF
---------
Co-authored-by: Claude <noreply@anthropic.com>
0 commit comments