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/CAJn%3DMYaFvFwqmw-Tx%2B%2B7dgzNY4ho82-6OL%3DUsNNXc7PLYjU0zA%40mail.gmail.com.
