Skip to content

Reuse the open PWA window when an email link launches the app - #154

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

Reuse the open PWA window when an email link launches the app#154
ralyodio merged 1 commit into
mainfrom
worktree-pwa-launch-handler

Conversation

@ralyodio

Copy link
Copy Markdown
Contributor

The problem

Clicking a link in an alert email opened the installed PWA in a new window every time. Working through a digest left one app window per post.

Why

Alert emails link at our own reader page — packages/notify/src/render.js builds ${origin}/{slug}/read?p={guid} — so every click is an in-scope launch of rssamplifier.com. apps/web/public/manifest.webmanifest declared no launch_handler, which leaves the browser on auto, and auto opens a new app window per launch.

The fix

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

navigate-existing focuses the most recently used app window and navigates it to the launched URL. That is the right mode here rather than focus-existing: the email link names a specific post, so landing on that post in the window already open is the point.

auto follows as the fallback for a browser that does not understand the first value, and for the case where no window is open yet.

What did not need changing

The notificationclick handler in sw.js already reuses a window by hand (clients.matchAllfocusnavigate). That path never went through the launch handler, which is why push taps were already fine and only email links were not.

sw.js VERSION goes v6 → v7 because /manifest.webmanifest is one of SHELL_URLS, so the copy taken at install is now stale. That bump is hygiene, not the fix — nothing serves the cached manifest today (.webmanifest falls through the fetch handler to the network), and the browser reads launch_handler over the network regardless.

Compatibility

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

Testing

  • manifest.webmanifest parses as valid JSON with the new key
  • node --check apps/web/public/sw.js passes
  • No test asserts on either file (apps/web/test/proxy.test.js only checks that the proxy matcher skips these paths, unaffected)

🤖 Generated with Claude Code

https://claude.ai/code/session_013FR5zDT4DGJAmwDb6oVZ6n

An alert email links at our own reader page, so on a device where the app
handles its own links every click was a launch of rssamplifier.com within
scope. The manifest declared no launch_handler, which leaves the browser on
`auto` — and `auto` opens a new app window per launch. Somebody working
through a digest ended up with one window per post.

`navigate-existing` focuses the app window that was used most recently and
navigates it to the launched URL instead, which is what the reader wants
here: the link names a specific post, so arriving at that post in the window
already open is the whole point. `auto` follows it in the list as the
fallback for a browser that does not know the first value, and for the case
there is no window open yet.

Nothing else was needed. The notification click handler already reuses a
window by hand (clients.matchAll, then focus and navigate) — that path never
went through the launch handler, which is why push taps were fine and email
links were not.

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 5e1b57a into main Aug 29, 2026
3 checks passed
@ralyodio
ralyodio deleted the worktree-pwa-launch-handler branch August 29, 2026 07:39
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