Skip to content

Reuse the open PWA window when an emailed link launches the app - #6

Merged
ralyodio merged 1 commit into
masterfrom
pwa-launch-handler
Aug 29, 2026
Merged

Reuse the open PWA window when an emailed link launches the app#6
ralyodio merged 1 commit into
masterfrom
pwa-launch-handler

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

The same fix just shipped for rssamplifier.com (profullstack/rssamplifier.com#154), applied here.

The problem

Clicking the sign-in link in an email opens the installed PWA in a new window every time instead of reusing the one already open.

Why

src/app/api/auth/magic/route.ts builds the magic link from the site's own origin(), so every click is an in-scope launch of p0dcasters. src/app/manifest.ts named no launch_handler, which leaves the browser on auto — and auto opens a new app window per launch.

For a magic link this is the worst shape the bug takes: the session cookie is set in whichever window opened the link, so you end up signed in inside a window you did not open, while the window you were already using sits there signed out, looking like the link failed.

The fix

launch_handler: {
  client_mode: ["navigate-existing", "auto"],
},

navigate-existing hands the launch to the most recently used app window and navigates it, so the link lands where you are already looking and the cookie is set in the window you were using. auto trails it for browsers that do not know the first value, and for when no window is open yet.

MetadataRoute.Manifest in Next 15.5 types this natively (client_mode: ClientModeEnum | ClientModeEnum[], with both values in the enum), so no cast or escape hatch is needed.

What did not need changing

Unlike rssamplifier, no service worker bump. public/sw.js here precaches nothing and never caches the manifest, so there is no stale copy for a version sweep to evict.

Compatibility

Chromium 110+ honours it. Safari and Firefox ignore launch_handler and keep their current behaviour. iOS home-screen installs open email links in Safari rather than the app either way.

Testing

  • npx tsc --noEmit passes (exit 0)
  • pnpm build succeeds
  • The generated manifest was checked, not just the source — .next/server/app/manifest.webmanifest.body contains "launch_handler":{"client_mode":["navigate-existing","auto"]}

🤖 Generated with Claude Code

https://claude.ai/code/session_013FR5zDT4DGJAmwDb6oVZ6n

The sign-in mail links back at our own origin — api/auth/magic builds the URL
from origin() — so on a device where the app handles its own links, clicking
it is an in-scope launch of p0dcasters. The manifest named no launch_handler,
which leaves the browser on `auto`, and `auto` answers every launch with a new
app window.

For a magic link that is the worst shape the bug takes. The session cookie is
set in whichever window opened the link, so you end up signed in inside a
window you did not open while the one you were already using sits there signed
out, looking like the link failed.

`navigate-existing` hands the launch to the window used most recently and
navigates it, so the link lands where you are already looking and the cookie is
set in the window you were using. `auto` follows it for a browser that does not
know the first value, and for when nothing is open yet.

No service worker change is needed here: public/sw.js precaches nothing and
never caches the manifest, so there is no stale copy for a version bump to
evict.

Safari and Firefox ignore launch_handler and keep their current behaviour.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013FR5zDT4DGJAmwDb6oVZ6n
@ralyodio
ralyodio merged commit 0993d0a into master Aug 29, 2026
2 checks passed
@ralyodio
ralyodio deleted the pwa-launch-handler branch August 29, 2026 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant