fix(notify): Rust-side unread toast fallback where the page never notifies - #24
Open
karem505 wants to merge 1 commit into
Open
fix(notify): Rust-side unread toast fallback where the page never notifies#24karem505 wants to merge 1 commit into
karem505 wants to merge 1 commit into
Conversation
…age never notifies (#3) The v0.3.3 diagnostic build proved that on some Windows 11 installs WhatsApp Web never calls window.Notification NOR ServiceWorkerRegistration.showNotification (log: session start + AUMID registered, but no `commands::notify` when messages arrive), so the JS-driven path silently produces no toast. A page-injected script cannot reach the service worker's own context, so the fallback must live in Rust. - set_unread: detect unread-count rises from the <title> and raise a Rust-side toast (count only, generic body — no PII) - notify: record_shim_notify() marks a page-driven toast so the fallback stays quiet for 10s (SHIM_GRACE) — no double toast for the same message - maybe_unread_toast gates: app locked -> suppress; notifications disabled -> suppress; account window focused -> suppress; shim fired within grace -> suppress; same count within 90s -> suppress - attribution + logging follow the existing no-PII dlog rules
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #3 (Windows toasts never appearing on installs where the page never notifies).
Root cause (from the existing diagnostics)
The v0.3.3 file-based diagnostic build already isolated this: on the reporter's Windows 11 install the log showed
session start+ AUMID registered +SetCurrentProcessExplicitAppUserModelID ok, but nocommands::notifyline ever appeared when messages arrived — while a standalone PowerShell toast for our AUMID rendered fine. Two users confirmed still broken in v0.6.2/v0.6.3.Conclusion: on some installs WhatsApp Web never calls
window.NotificationnorServiceWorkerRegistration.prototype.showNotification(our two shimmed paths). The failure is upstream of the OS toast layer, and a page-injected script cannot reach the service worker's own context — so no amount of JS shimming can fully cover it.What this PR does
Drives a toast from Rust using the one signal WhatsApp always updates: the unread count in the document
<title>, already forwarded by bridge.js viaset_unreadon every change (plus a 2s poll).set_unread: when an account's unread count rises, raise a Rust-side toast. Body is a generic count ("You have N unread messages.") — this layer never sees message content, so the no-PII rule holds.notify(the page-driven path) now callsrecord_shim_notify(label); the fallback stays silent for 10s after any page-driven toast, so installs where the JS path works never see double toasts.commands::notify: suppressed while app-locked, when notifications are disabled, and when the account window is visible and focused. A same-count repeat within 90s is suppressed (title re-polls/re-renders).Verification
cargo test --lib: 85 passed (2 new constant-sanity tests)Known limitation (documented in code)
The fallback knows that messages arrived (count), not who sent them, so its body is generic. On installs where the page's JS path works, real-content toasts continue to come from the shim. Fully content-rich toasts on broken installs would need the service-worker context, which a page-injected script cannot reach — happy to explore a dedicated injection route if this fallback proves the toast layer works on the affected machines.
Feedback from reporters on affected Windows 11 machines is what actually validates this — requesting it in the issue.