Problem
In the demo blog, sending a live chat message sends the message but then the
page scrolls to the top and the just-sent message disappears. Same class of bug
applies to the live comments thread.
Root cause
The client router's submit listener is registered on document in CAPTURE
phase (router-client.js enableClientRouter:
document.addEventListener('submit', onSubmit, true), from #e59f381). The
renderer binds a component's @submit handler per-element, which runs in the
at-target / bubble phase (render-client.js). So for a JS-handled form (the
chat/comments forms call e.preventDefault() in @submit and send via
WebSocket / fetch), the router's capture-phase onSubmit runs FIRST, before the
component's handler. Its guard if (e.defaultPrevented) return; therefore sees
false (the component has not run yet), so the router does NOT skip: it
resolves the action (these forms have no action, so it falls back to the
current URL), preventDefaults, and does performSubmission, navigating the
page. The component's @submit then also runs (sends the message). Net: the
message is sent AND the page navigates / swaps, scrolling to the top and wiping
the WebSocket-driven chat state.
The documented contract (AGENTS.md: "Forms that already e.preventDefault()
in @submit are untouched") is defeated by the capture-phase registration: the
defaultPrevented guard only works if the router runs AFTER the form's own
handler, i.e. in the BUBBLE phase. Mirrors hotwired/turbo, which does the
submission work in a bubble listener.
Fix
Register the submit listener in the bubble phase (capture false) in both
enableClientRouter and disableClientRouter, so a component's @submit
preventDefault is seen by the defaultPrevented guard and the router leaves
the form alone. Plain progressive-enhancement forms (no @submit) still get
intercepted and SPA-submitted, since nothing prevents their default.
Acceptance criteria
Problem
In the demo blog, sending a live chat message sends the message but then the
page scrolls to the top and the just-sent message disappears. Same class of bug
applies to the live comments thread.
Root cause
The client router's
submitlistener is registered ondocumentin CAPTUREphase (
router-client.jsenableClientRouter:document.addEventListener('submit', onSubmit, true), from #e59f381). Therenderer binds a component's
@submithandler per-element, which runs in theat-target / bubble phase (
render-client.js). So for a JS-handled form (thechat/comments forms call
e.preventDefault()in@submitand send viaWebSocket / fetch), the router's capture-phase
onSubmitruns FIRST, before thecomponent's handler. Its guard
if (e.defaultPrevented) return;therefore seesfalse(the component has not run yet), so the router does NOT skip: itresolves the action (these forms have no
action, so it falls back to thecurrent URL),
preventDefaults, and doesperformSubmission, navigating thepage. The component's
@submitthen also runs (sends the message). Net: themessage is sent AND the page navigates / swaps, scrolling to the top and wiping
the WebSocket-driven chat state.
The documented contract (
AGENTS.md: "Forms that alreadye.preventDefault()in
@submitare untouched") is defeated by the capture-phase registration: thedefaultPreventedguard only works if the router runs AFTER the form's ownhandler, i.e. in the BUBBLE phase. Mirrors hotwired/turbo, which does the
submission work in a bubble listener.
Fix
Register the
submitlistener in the bubble phase (capturefalse) in bothenableClientRouteranddisableClientRouter, so a component's@submitpreventDefaultis seen by thedefaultPreventedguard and the router leavesthe form alone. Plain progressive-enhancement forms (no
@submit) still getintercepted and SPA-submitted, since nothing prevents their default.
Acceptance criteria
@submitcallspreventDefaultis NOT intercepted by the router (no navigation)<form action method>with no JS handler still SPA-submits via the router