This repository was archived by the owner on Mar 10, 2026. It is now read-only.
Open
Conversation
added 2 commits
March 8, 2026 14:37
… audio, media session) - resolveSilent = () => false — OS/Sygnal handles push sound entirely; the in-app sound setting no longer affects push notification sound - remove notificationSoundEnabled from SW postMessage payload - move OS notification block before visibilityState guard so desktop notifications fire even when the browser window is minimised - pass isEncryptedRoom:false for in-app banner preview — events are already decrypted by the SDK so the actual message body is always shown - call clearMediaSessionQuickly() after play() to dismiss the iOS lock screen media player; only clears playbackState if no real media metadata is set
The banner placement move (ClientNonUIFeatures -> ClientLayout) belongs in the separate fix/notification-banner PR. Keep the render here so Knip does not report the banner files as unused on this branch.
Just-Insane
pushed a commit
to CloudHub-Social/sable
that referenced
this pull request
Mar 9, 2026
added 4 commits
March 9, 2026 13:12
… sound tweak Two bugs caused by sliding sync's limited required_state (only $ME member): 1. DM badge was grey instead of green Synapse sends highlight_count=0 for DMs without mention; the badge only showed as Success (green) when highlight>0. DMs should always display the green badge for any unread. Fix: RoomNavItem treats direct && total>0 as highlight for the UnreadBadge highlight prop. 2. DM OS notification was silent PushProcessor evaluates .m.rule.room_one_to_one by checking room_member_count==2, but with only m.room.member/$ME in required_state the member count is 1, so the rule fails. Events fall through to .m.rule.message (notify, no sound), leaving loudByRule=false and the OS notification silent:true. Fix: isLoud = loudByRule || isDM so that known DM rooms always produce non-silent notifications when sounds are on.
…ual mentions/replies
useNotificationJumper was using roomToParents.get(roomId) — the direct parent set — which could be a subspace rather than a root-level space. The router only recognises /space/<root-space-id>/room paths, so linking via a subspace ID would hit JoinBeforeNavigate instead of opening the room. Replace with the same logic as useRoomNavigate: getOrphanParents() walks the full hierarchy to find root-level spaces, guessPerfectParent() picks the best one to route through.
…p in try/catch
Two bugs caused in-app notifications to silently vanish on desktop when
the window was focused:
1. window.Notification() was called unconditionally even when the window
had focus. In some browsers/environments (certain Chrome versions,
Electron, macOS DnD mode) calling the Notification constructor throws
or is silently rejected when the tab is active. Without a try/catch
the uncaught exception aborted the entire RoomEvent.Timeline handler
before setInAppBanner was ever reached — so neither the OS notification
NOR the in-app banner appeared. InviteNotifications already used
try/catch for the same reason; MessageNotifications did not.
2. The OS notification was semantically wrong when focused: the in-app
banner is the correct alert while the window is active. Added a
!document.hasFocus() guard to match the comment's stated intent
("alert when minimised or tab not active") and to prevent a duplicate
OS+in-app banner when another window is simply on top.
Mobile is unaffected: mobileOrTablet() already gates the OS block.
The in-app banner path (visibilityState === 'visible' → setInAppBanner)
is unchanged and continues to fire correctly on both desktop (focused)
and mobile (app visible in browser).
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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Summary
Fixes several bugs in how notifications are delivered and played.
Fixes
resolveSilentin the service worker now always returnsfalse, leaving sound/vibration decisions entirely to the OS and Sygnal push gateway. The in-app sound setting no longer affects push sound.mobileOrTablet()check. It now fires on all platforms when In-App Notifications is enabled.isEncryptedRoom: falseis now passed so the actual message body is shown when content preview is enabled.visibilityState !== 'visible'guard (which only gates the in-app banner and audio). Notifications now fire when the browser window is minimised.mediaSession.playbackStateis cleared after a short delay followingplay(). If in-app media has since registered its own metadata the session is left untouched.Changed files
src/app/pages/client/ClientNonUIFeatures.tsxmobileOrTablet()gate; move OS notification block before visibility guard; passisEncryptedRoom: false; callclearMediaSessionQuickly()afterplay()src/sw.tsnotificationSoundEnabledfrom postMessage payloadsrc/sw/pushNotification.tsresolveSilent = () => false