Recreating the subscription removed the account's stored id before the
replacement was created and verified, and the resync now requires that
id. One interrupted or timed-out attempt (up to 75 seconds of
verification) therefore ended recovery for that account for good. The
id now stays until a verified replacement overwrites it.
A failed resync also forgot its timestamp, so every return to the tab
reran the whole enable. It now waits 15 minutes before the next try.
The background re-sync skipped any account whose browser subscription
was gone (isWebPushEnabled needs a live one), which is exactly the
state that needs repairing: the browser or the user cleared the
endpoint while the opt-in and the server registration survived, and
push stopped for good. It now runs whenever the user opted in and
permission is granted, so the normal enable flow recreates the
subscription. It still never prompts. A failed attempt no longer waits a
day for the next one.
Firefox rejects pushManager.getSubscription() with
`AbortError: Error retrieving push subscription` when its local push
record is stale or the push service is unreachable. enableWebPush let
that reject the whole call, so the onboarding banner showed the browser's
bare error and push could never be turned on again - even though
subscribing fresh is exactly the recovery.
Treat a failed lookup as "no subscription to reuse" and continue to
subscribe(), whose error still surfaces when the push service is really
unavailable. Same reasoning for unsubscribe() of a mismatched
subscription: getting the new subscription is what matters.
Claude-Session: https://claude.ai/code/session_019KwXZEwxijHRbfobfXmcK2
Bulwark asks for a 90-day push subscription, but Stalwart clamps
`expires` to 7 days. The background renewal ran once per page load,
so a tab or installed app left open for more than a week let the
subscription lapse and notifications stopped without a hint.
The renewal now runs at most once a day instead of once per load, and
also when the tab comes back to the foreground.
The notification panel only ever addresses the account on screen, so
arming a browser for five accounts meant switching account five times
and answering the same permission prompt on each pass.
The browser holds a single push subscription: enabling an account
registers it against that one subscription rather than creating another.
A section in the notification settings now lists every connected account
with its current state and turns push on or off for the ones selected,
walking them against the same subscription.
A refusal at the browser level - unsupported, or permission denied -
applies to every account, so it stops the walk instead of failing each
account in turn and prompting repeatedly.
enableWebPush reused any existing browser PushSubscription that exposed an
applicationServerKey, without comparing that key to the relay's. A push
subscription is bound to the key it was created with. So a browser that
subscribed against another relay, or before this relay rotated its keys,
kept a subscription the push service rejects on every send. Mozilla
answers 401 "VAPID public key mismatch". isWebPushEnabled still reports
push as on, so nothing prompts the user to fix it.
Compare the key bytes and resubscribe on a mismatch. Because
resyncWebPush runs enableWebPush on app start, affected browsers repair
themselves the next time the app opens.
Claude-Session: https://claude.ai/code/session_019KwXZEwxijHRbfobfXmcK2
Linus Rath
lucamzanon
Linus Rath
Shuki Vaknin
Aaron Guise