LGTM1 On Wednesday, February 4, 2026 at 11:53:18 AM UTC+1 Noam Rosenthal wrote:
> On Wed, Feb 4, 2026 at 4:47 AM Yoav Weiss (@Shopify) > <[email protected]> wrote: > > > > > > > > On Tuesday, February 3, 2026 at 1:36:06 PM UTC+1 Chromestatus wrote: > > > > Contact emails > > [email protected] > > > > Explainer > > https://github.com/WICG/navigation-api/pull/294 > > > > > > A bit more details would be useful here. > > Even reading through > https://github.com/WICG/navigation-api?tab=readme-ov-file#precommit-handlers, > the role of post-commit handlers, nor how does one define them today is not > clear. > > > > I *think* I have a vague idea, so let me try to take a stab and let me > know if I got it right. > > Currently a developer that wants to add a post-commit handler (or simply > a `handler` in the current API) to e.g. send analytics that a navigation > has happened, can do that using > > ``` > > navigation.addEventListener("navigate", e => { > > if (e.canIntercept) { > > const handler = sendAnalytics(e); > > e.intercept({ handler }); > > } > > }); > > ``` > > > > When they want to do something pre-commit (e.g. cancel the navigation if > the target URL doesn't lead to a cat video), they can do something like > > ``` > > navigation.addEventListener("navigate", e => { > > if (e.canIntercept) { > > const precommitHandler = verifyCatVideo(controller); > > e.intercept({ precommitHandler }); > > } > > }); > > ``` > > They can even add both. > > > > But when developers today want to add a post-commit (or "regular") > handler as a result of some handler in the pre-commit, they have no way of > doing that. > > > > This proposal is to add an `addHandler` method to the precommit > controller, that would enable to add such post-commit handlers. > > > > Is that roughly accurate? > > Yes! > > > If so, what would be an example use-case of wanting to add a post-commit > handler as a result of pre-commit logic? What information does the > pre-commit handler have that a post-commit logic doesn't? > > Something like this, where the precommit handler performs some logic > to understand what to do with the request, and perhaps begins some > sort of shell, to be later populated by the handler: > ```js > navigation.addEventListener("navigate", e => { > if (e.canIntercept) { > e.intercept({ > async precommitHandler(controller) { > if (should_redirect(e.destination.url)) [ > e.redirect(new_url); > return; > } > else if (should_cancel(destination.url)) { > throw new Error("cancel this navigation"); > } > const contentPromise = fetchPageData(); > const shell = await fetchPageShell(); > > shell.show_skeleton(); > > controller.addHandler(() => show_actual_data(await contentPromise)); > } > } > }); > ``` > > Doing it this way is slightly more ergonomic than managing promises > outside of the intercept call. > See > https://github.com/WICG/navigation-api/issues/66#issuecomment-1199002825 > for old discussion about this. > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b905747b-d4bd-4b7e-90fe-5b2965ee93a7n%40chromium.org.
