Files
multica/packages/views/navigation/context.tsx
Bohan Jiang 1fef98c24f fix(desktop): open in-app links in a tab instead of the browser (MUL-5208) (#5826)
* fix(desktop): open in-app links in a tab instead of the browser (MUL-5208)

A link written as an absolute URL on this deployment's own origin
(`https://<app-host>/acme/issues/1` — what "copy link" produces, and what
agents paste into chat) fell through openLink's external branch to
window.open, which Electron routes to shell.openExternal. Clicking an issue
link in Desktop chat therefore opened a browser window instead of a tab.

openLink now resolves such a URL back to its in-app path and takes the same
route a relative path does. Backend-served prefixes (/api/, /_next/) stay
external so attachment downloads keep working.

Two supporting fixes the change depends on:

- The `multica:navigate` event had no listener on web, so in-app paths in
  content were dead links there; normalizing app URLs would have extended
  that to every pasted app URL. The web platform layer now answers the event
  with a router push.
- The desktop handler opened every path inside the active workspace's tab
  group. A cross-workspace link now goes through switchWorkspace, matching
  what the navigation adapter already does for pushes.

Co-authored-by: multica-agent <github@multica.ai>

* fix(desktop): scope in-app link conversion to workspace pages, answer it in issue windows

Review follow-ups on MUL-5208.

1. The non-page exclusion list only covered /api/ and /_next/, so a
   same-origin /uploads/* link — local-storage attachments, served by the
   backend and proxied by web — was routed as an app page, opening a dead tab
   instead of the file. Replaced the deny-list with the app's own routing
   model: an absolute URL converts to an in-app path only when its first
   segment is a slug a workspace could own, which the existing reserved-slug
   list (shared with the backend) already answers. /api, /uploads, /_next,
   /favicon.ico and the pre-workspace routes all stay external without a
   second list to keep in sync.

2. A dedicated issue window derives the same app origin from its adapter but
   had no multica:navigate listener, so a same-origin link there became a
   silent no-op (it used to reach the browser). The window now answers the
   event: another issue opens in place — matching what its adapter push and
   mention chips already do — and any other app page, which this single-route
   window cannot host, goes to the browser.

Co-authored-by: multica-agent <github@multica.ai>

---------

Co-authored-by: J <agent@multica.ai>
Co-authored-by: multica-agent <github@multica.ai>
2026-07-23 16:50:23 +08:00

60 lines
2.0 KiB
TypeScript

"use client";
import { createContext, use, useMemo, useTransition } from "react";
import type { NavigationAdapter } from "./types";
const NavigationContext = createContext<NavigationAdapter | null>(null);
const NavigationPendingContext = createContext<boolean>(false);
export function NavigationProvider({
value,
children,
}: {
value: NavigationAdapter;
children: React.ReactNode;
}) {
// Wrap push/replace in startTransition so any caller of useNavigation()
// (sidebar AppLink, command palette, modal post-create jumps) gets a
// React pending signal during route commit. On web this stays true until
// Next.js commits the new RSC payload; on desktop it flips off quickly
// because react-router commits synchronously — both are correct.
const [isPending, startTransition] = useTransition();
const wrapped = useMemo<NavigationAdapter>(
() => ({
...value,
push: (path: string) => startTransition(() => value.push(path)),
replace: (path: string) => startTransition(() => value.replace(path)),
}),
[value],
);
return (
<NavigationContext.Provider value={wrapped}>
<NavigationPendingContext.Provider value={isPending}>
{children}
</NavigationPendingContext.Provider>
</NavigationContext.Provider>
);
}
/**
* Non-throwing read of the adapter. For components that legitimately render
* outside a provider — leaf editor UI mounted in isolation, and the tests that
* exercise it — where the navigation-dependent behaviour has a sane fallback.
* Anything that must navigate should use `useNavigation()` and keep the throw.
*/
export function useOptionalNavigation(): NavigationAdapter | null {
return use(NavigationContext);
}
export function useNavigation(): NavigationAdapter {
const ctx = use(NavigationContext);
if (!ctx)
throw new Error("useNavigation must be used within NavigationProvider");
return ctx;
}
/** True while a transition-wrapped push/replace is committing. */
export function useIsNavigating(): boolean {
return use(NavigationPendingContext);
}