Say what "even when ihasmail is closed" actually means #74

New Issue

Closed

opened 2026-08-26 21:13:17 +00:00 by jcoffey-dev · 0 comments

jcoffey-dev commented

2026-08-26 21:13:17 +00:00

Owner

But "closed" means ihasmail, not the browser — and the switch didn't say so.

Web Push is delivered over a connection the browser holds, so something of it has to be running. Observed today with Chrome fully quit and Continue running background apps off: nothing arrived until Chrome was started again, at which point the queued notification was delivered.

state	result
Chrome open, no ihasmail tab	immediate, with sender and subject
Chrome quit, background apps on	immediate (a process survives)
Chrome quit, background apps off	queued; arrives when Chrome next starts

One further caveat worth recording: the queue isn't indefinite. A Web Push message carries a TTL, and one that expires before the browser returns is dropped, not delivered late.

Being an installed PWA doesn't change this on desktop — it changes the window, not who holds the connection. On Android it would, since the push service can wake the browser from cold.

What changed

Nothing in behaviour. The README entry and the settings hint now say what's true:

Your mail server delivers these straight to your browser, so they arrive with no ihasmail tab open, naming the sender and subject. Your browser still has to be running — if you quit it completely, notifications wait and arrive when you open it again.

None of this is ihasmail's to fix; it's what Web Push is on a desktop. The only thing worth doing about it is not implying otherwise, which the switch was quietly doing.

Docs only — no code. 265 web + 75 server tests, typecheck clean.

Merged 2026-08-26 as coffey-labs/ihasmail@b37c422e7d

_{Rebuilt from: git history, session transcript.}

Web Push works. Confirmed end to end against the live 0.16.19: Chrome open, every ihasmail tab closed, notification arrives immediately naming the sender and subject. Subscription, verification handshake, VAPID signing and the service worker's `push` handler all doing their jobs. **But "closed" means ihasmail, not the browser — and the switch didn't say so.** Web Push is delivered over a connection the *browser* holds, so something of it has to be running. Observed today with Chrome fully quit and *Continue running background apps* off: nothing arrived until Chrome was started again, at which point the queued notification was delivered. | state | result | |---|---| | Chrome open, no ihasmail tab | immediate, with sender and subject | | Chrome quit, background apps **on** | immediate (a process survives) | | Chrome quit, background apps **off** | queued; arrives when Chrome next starts | One further caveat worth recording: the queue isn't indefinite. A Web Push message carries a TTL, and one that expires before the browser returns is **dropped**, not delivered late. Being an installed PWA doesn't change this on desktop — it changes the window, not who holds the connection. On Android it would, since the push service can wake the browser from cold. ## What changed Nothing in behaviour. The README entry and the settings hint now say what's true: > Your mail server delivers these straight to your browser, so they arrive with no ihasmail tab open, naming the sender and subject. **Your browser still has to be running** — if you quit it completely, notifications wait and arrive when you open it again. None of this is ihasmail's to fix; it's what Web Push is on a desktop. The only thing worth doing about it is not implying otherwise, which the switch was quietly doing. Docs only — no code. 265 web + 75 server tests, typecheck clean. **Merged** 2026-08-26 as coffey-labs/ihasmail@b37c422e7d72 <sub>Rebuilt from: git history, session transcript.</sub>

This repo is archived. You cannot comment on issues.

1 Participants

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: coffey-labs/ihasmail-github-archive#74