Hey, Can you please file signals for other browser vendors?
Thanks! Vlad On Wednesday, February 4, 2026 at 11:20:25 AM UTC-5 Alex Russell wrote: > 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/6350f573-57be-41b4-8d94-cec255f9893cn%40chromium.org.
