Skip to content

fix(desktop): notify for the selected channel when the window is unfocused - #7123

Open
mdschoff wants to merge 1 commit into
block:mainfrom
mdschoff:fix/desktop-active-channel-focus-suppression
Open

mdschoff wants to merge 1 commit into
block:mainfrom
mdschoff:fix/desktop-active-channel-focus-suppression

Conversation

@mdschoff

Copy link
Copy Markdown

Problem

DM and thread-reply desktop notifications are suppressed for the currently selected channel, but the check only compares channel ids — it never asks whether the app window is actually focused. Leaving a DM conversation selected and minimizing (or backgrounding) the app silently drops every notification for that conversation — the one the user is most likely waiting on. useLiveChannelUpdates.ts previously:

if (channelId === activeChannelId && !options.notifyForActiveChannel) return;

How it was implemented

  • New pure predicate isSuppressedAsActiveChannel() in desktop/src/features/channels/activeChannelSuppression.ts: a channel only counts as "being viewed" when it is the active channel and the app window is focused, using the existing isAppFocused() utility from shared/lib/useDocumentVisible.ts.
  • Both suppression sites in useLiveChannelUpdates.ts (the DM path and the thread-reply desktop-notification path) now share the predicate, evaluated at event-delivery time.
  • The notifyForActiveChannel (notify-while-viewing) opt-in still bypasses suppression entirely, and behavior while the app is focused is unchanged.
  • Regression tests in activeChannelSuppression.test.mjs, including the minimized-window case.

How to test manually

  1. Open a DM conversation in the desktop app and keep it selected.
  2. Minimize the app (or focus another application).
  3. Have the other participant send a DM.
  4. Before: no notification. After: OS notification + sound + dock bounce fire as they do for any non-active channel.
  5. Re-focus the app with the DM still selected and receive another message: still suppressed (unchanged), unless the notify-while-viewing setting opts in.

No UI changes — behavior-only, so no screenshots.

Verification

  • desktop: pnpm test — 5,804 pass (5 new)
  • desktop: pnpm typecheck, pnpm check, pnpm build — clean

Related

Searched open PRs and issues for duplicates — none found for this specific bug. Closest neighbors: #6276 (mentions don't notify while unfocused — different mechanism, the home-feed poll pausing) and the notify-while-viewing setting added in #753. Follow-up candidate deferred to a future PR: fixing #6276 itself.

…cused

DM and thread-reply desktop notifications are suppressed for the
currently selected channel, but the check only compared channel ids —
it ignored whether the window was actually focused. Leaving a DM
conversation open and minimizing the app silently dropped every
notification for that conversation, the one the user is most likely
waiting on.

Gate the suppression on isAppFocused(): a channel selected in a
blurred or hidden window is not being viewed, so notifications for it
fire again. The notifyForActiveChannel opt-in still bypasses
suppression entirely. The decision is extracted into a pure
isSuppressedAsActiveChannel() predicate shared by both the DM and
thread-reply paths, with regression tests.

Signed-off-by: mdschoff <mdschoff@gmail.com>
@mdschoff
mdschoff requested a review from a team as a code owner August 31, 2026 17:42
@github-actions

Copy link
Copy Markdown

🔐 Codex Security Review

Status: review required for the current range.

The current range is bc006f67087b049e2f9c4d8a2f26faceff628225...736c5eb30d867164125fb2e496dd87ef44a50297.
A new review must complete for this exact range. When manual authorization
is required, a Block organization member must comment exactly
@buzz-security-review 736c5eb30d867164125fb2e496dd87ef44a50297 to authorize a new review.
Any previous review applies only to its recorded range.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant