LGTM2 On Wednesday, February 4, 2026 at 8:16:28 AM UTC-8 Yoav Weiss wrote:
> 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/3e7aaf77-53a6-4311-881c-780eecf27dffn%40chromium.org.
