fix(push): make web push subscription explicit and eager (LC-343) #456
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/LC-343-push-subscription-flow"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Root cause of non-delivery: the push subscription was chicken-and-egg lazy. tryRegisterPush() only ran from fireNotification(), which only fires on a background Mentioned event, and only after Notification.permission is already 'granted'. There was no affordance to grant permission and no registration on page load, so a user who had not received a background mention while already permission-granted never had a push_subscriptions row created. With no row, push::dispatch had nothing to send to, so push never fired regardless of LETS_CHAT_SECRET_KEY, the notify_push_enabled toggle, or the VAPID key being present.
Fixes the activation/subscription flow (web/desktop only; APNs/FCM stay deferred per LC-91):
New en/es catalog keys for the button, help text, and status messages; the JS-embedded status strings avoid apostrophes/quotes so the HTML escaper does not mangle them inside the script body.
#LC-343
The "Enable desktop notifications" button subscribed the browser and always reported settings-push-status-ok ("This device will receive push notifications"), but push::dispatch early-returns unless the SAVED notify_push_enabled is on. A user who clicked the button with the toggle off (or flipped it on but never submitted the preferences form) got a green success line while the server silently dropped every push. Report the new settings-push-status-ok-toggle-off variant when pushEnabled (which mirrors the saved toggle) is false, so the success line tells them to turn the toggle on and save; the plain ok line stays for the already-saved-on case. The subscription itself still succeeds in both cases (data-lc-push-ok stays 1). Also move the status strings out of JS string literals and into data-* attributes on the cfg div, read via getAttribute. The template HTML-escaper makes a translation containing a quote or apostrophe safe there; the previous inline form only worked because every string happened to avoid quotes, which a future locale or translator would not guarantee. i18n_catalog and routes_settings_feedback pass; the new key is defined in both en and es so locale parity holds. #LC-343 Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>