Problem
Follow-up surfaced while fixing #150 (the form-submit capture bug). The client
router's click listener is registered on document in CAPTURE phase
(router-client.js enableClientRouter: addEventListener('click', onClick, true)), and onClick has the same if (e.defaultPrevented) return guard as
onSubmit did. A component's @click handler is bound per-element (at-target),
so it runs AFTER the document capture listener. So a JS-handled link, e.g. a
custom element rendering <a href="..." @click=${e => { e.preventDefault(); doSomethingInJs(); }}> (an in-component menu toggle, a JS-driven action link),
would be hijacked by the router and navigated, before the component's
preventDefault runs. Same class of bug as #150, for clicks instead of submits.
It does not bite the demo blog (its nav is plain <a href> and its
interactivity is forms), which is why #150 fixed only submit and left click
capture. But the asymmetry is real and will bite an app with a JS-handled link.
Design / approach
Moving click to bubble (like #150 did for submit) would honor a component's
@click preventDefault. Needs care: the click path has more cases than submit
(modifier keys, middle-click, download, cross-origin, hash links, the existing
capture-phase tests). Verify nothing relies on capture ordering before flipping.
Acceptance criteria
Problem
Follow-up surfaced while fixing #150 (the form-submit capture bug). The client
router's
clicklistener is registered ondocumentin CAPTURE phase(
router-client.jsenableClientRouter:addEventListener('click', onClick, true)), andonClickhas the sameif (e.defaultPrevented) returnguard asonSubmitdid. A component's@clickhandler is bound per-element (at-target),so it runs AFTER the document capture listener. So a JS-handled link, e.g. a
custom element rendering
<a href="..." @click=${e => { e.preventDefault(); doSomethingInJs(); }}>(an in-component menu toggle, a JS-driven action link),would be hijacked by the router and navigated, before the component's
preventDefaultruns. Same class of bug as #150, for clicks instead of submits.It does not bite the demo blog (its nav is plain
<a href>and itsinteractivity is forms), which is why #150 fixed only
submitand leftclickcapture. But the asymmetry is real and will bite an app with a JS-handled link.
Design / approach
Moving
clickto bubble (like #150 did forsubmit) would honor a component's@clickpreventDefault. Needs care: the click path has more cases than submit(modifier keys, middle-click,
download, cross-origin, hash links, the existingcapture-phase tests). Verify nothing relies on capture ordering before flipping.
Acceptance criteria
<a @click=preventDefault>is NOT intercepted/navigated by the router<a href>links still SPA-navigate; modifier/middle clicks, downloads, cross-origin, hash-only still behave