[Due for payment 2026-06-26] [$250] Bug: No desktop notification when active chat is open and app is visible but unfocused (another app in foreground)

[melvin-bot]

Summary

When NewDot is open in a browser tab (visible but not focused — e.g. you've switched to Slack or another desktop app), and the chat with the message sender is the currently open report, no notification is received even though the user is not actively looking at it. The message is silently marked as read with no alert.

If any other chat is open when the same sender messages you, the notification fires correctly. The bug is specific to the case where the sender's chat is the active/open report.

---

Steps to Reproduce

1. Open NewDot in Chrome on macOS (web or PWA).
2. Open a DM chat with User A.
3. Switch focus to another desktop app (e.g. Slack, Finder) — do not minimize the NewDot window or switch browser tabs. The NewDot tab remains visible.
4. Have User A send you a message.

Expected: A desktop notification fires (because you are not actively viewing the chat).
Actual: No notification. The message is silently marked as read.

Contrast (works correctly): Repeat with a different chat open in NewDot → notification fires as expected when User A messages you.

---

Root Cause

This is a visible-vs-focused mismatch in two separate parts of the notification pipeline.

Step 1 — Browser visibility state when another app is focused

When the user switches to another desktop app (not another tab, not minimizing):

• document.visibilityState === 'visible' → Visibility.isVisible() = true
• document.hasFocus() = false

So to the app, the page is "visible" even though the user isn't looking at it.

Step 2 — Open chat auto-marks message as read (the actual bug)

In src/pages/inbox/report/ReportActionsList.tsx, handleReportChangeMarkAsRead fires when a new action arrives in the currently open report. Its gate checks isVisible only, not hasFocus:

if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
    readNewestAction(report.reportID, ...);  // advances lastReadTime immediately
}

Because isVisible is true (page is not hidden), lastReadTime is advanced to ≥ the incoming message's created timestamp — even though the user's focus is on Slack.

Step 3 — "Already read" gate suppresses the notification

In src/libs/actions/Report/index.ts — shouldShowReportActionNotification():

// If this notification was delayed and the user saw the message already, don't show it
if (action && report?.lastReadTime && report.lastReadTime >= action.created) {
    Log.info(`${tag} No notification because the comment was already read`);
    return false;
}

Since lastReadTime was just advanced in Step 2, this gate fires and the notification is dropped.

Note: the other suppression gate — reportID === topmostReportID && isVisible() && hasFocus() — does not fire here because hasFocus() is false. It's the "already read" gate that kills the notification, caused by the premature mark-as-read.

Why a different open chat avoids the bug

If Chuck's DM is not the open report, handleReportChangeMarkAsRead runs against whichever chat is open — Chuck's lastReadTime is never advanced, the "already read" gate passes, and the notification fires. This matches the observed behavior exactly.

---

Suggested Fix Direction

The mark-as-read logic in ReportActionsList.tsx should require focus (not just visibility) before auto-advancing lastReadTime, so a visible-but-unfocused tab does not silently consume messages. Concretely, the condition should be:

if ((isVisible && hasFocus || isFromNotification) && !hasNewerActions && isScrolledToEnd) {

Care is needed to avoid regressing the case where a user is genuinely reading the chat (visible + focused) — that should still mark as read immediately. The change should be limited to the "another desktop app is in the foreground" scenario.

---

Environment

• Platform: Web (Chrome), macOS — also likely affects PWA
• App version: 9.3.90-2 (confirmed in logs at time of reproduction)
• Browser: Chrome 148

QA Note

When reproducing, switch to another desktop application (do not minimize the NewDot window or switch browser tabs). Minimizing or switching tabs changes visibilityState to hidden, which is a different code path and does not reproduce the bug.

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022061521168242779419
• Upwork Job ID: 2061521168242779419
• Last Price Increase: 2026-06-08

Issue Owner

Current Issue Owner: @nabi-ebrahimi

[MelvinBot]

Proposal

What is the root cause of that problem?

When a new message arrives in the currently open report, handleReportChangeMarkAsRead auto-marks it read using a gate that checks visibility only, not window focus:

src/pages/inbox/report/ReportActionsList.tsx:578
if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd)

When you switch to another desktop app (without minimizing or changing tabs), document.visibilityState stays 'visible' but document.hasFocus() becomes false. So isVisible is true, the gate passes, and readNewestAction advances lastReadTime to "now".

The local-notification check then drops the notification at the "already read" gate, because lastReadTime was just advanced past the message's created:

src/libs/actions/Report/index.ts:4590

The other suppression gate — Report/index.ts:4569 (reportID === topmostReportID && isVisible() && hasFocus()) — does not fire here, because it correctly requires hasFocus(). So the premature mark-as-read is the real cause, not the notification gate.

Strong corroboration: the sibling mark-as-read path in the same file, handleAppVisibilityMarkAsRead (ReportActionsList.tsx:595), already gates on isVisible && isFocused. The report-change path uses a weaker gate (isVisible only) — an internal inconsistency. This also explains why a different open chat works: mark-as-read only touches the open report, so the sender's lastReadTime is never advanced and the "already read" gate passes.

What changes do you think we should make in order to solve the problem?

Require browser window focus (not just visibility) before auto-advancing lastReadTime in handleReportChangeMarkAsRead, so a visible-but-unfocused tab does not silently consume messages. The gate at line 578 should additionally require Visibility.hasFocus().

Important implementation nuance: do not reuse the component's existing isFocused variable (line 197) — that comes from React Navigation's useIsFocused() and means screen/route focus, which is true whenever the report is the active screen regardless of OS window focus. The correct signal is Visibility.hasFocus() (document.hasFocus()), read imperatively inside the gate.

The genuinely-reading case (visible and focused) is unaffected: it still marks read immediately, and gate 4569 still suppresses the redundant notification.

What alternative solutions did you explore? (Optional)

• Tighten the "current report" notification gate at Report/index.ts:4569 — rejected. That gate already correctly checks hasFocus(); the bug is the premature mark-as-read upstream, not the notification check.

Investigation details, confidence & QA notes

Notification trigger path: local notifications fire via triggerNotifications → showReportActionNotification → shouldShowReportActionNotification, invoked after the Pusher Onyx update is applied (User.ts:977).

Confidence: Medium-High. The code mechanism, the two gates, and the sibling-path inconsistency are all confirmed by static reading and match the reported behavior exactly (including the "different chat works" contrast). The one part I could not prove from code alone is the precise race ordering — that the effect-driven mark-as-read in ReportActionsList reliably advances lastReadTime before triggerNotifications reads it. The reported reliable reproduction strongly implies it does, and notably the proposed fix is correct regardless of the exact ordering: removing the premature mark-as-read in the unfocused case eliminates the race entirely. I did not query production logs because the issue carries no reportID/accountID to isolate occurrences, and the relevant log string (No notification because the comment was already read) is high-volume (it also fires for genuinely-read messages).

QA edge case to confirm: regaining OS focus on an already-visible tab does not fire a visibilitychange event, so handleAppVisibilityMarkAsRead won't re-mark on focus regain. After the fix, the unread/new-message marker should persist until the user scrolls or interacts — verify this is acceptable.

---

Next Steps for Contributor+ team:
To accept: @MelvinBot implement [this](https://github.com/Expensify/App/issues/92273) to create a draft PR.
To refine: @MelvinBot <your feedback>
To reject: Explain why you are rejecting Melvin's proposal.

[KJ21-ENG]

🚨 Edited by proposal-police: This proposal was edited at 2026-06-01 18:59:08 UTC.

Proposal

What is the root cause of that problem?

The open-report "mark as read" path treats a visible browser tab as proof that the user saw the new message.

On web, Visibility.isVisible() only checks document.visibilityState === 'visible', while Visibility.hasFocus() checks document.hasFocus():

App/src/libs/Visibility/index.ts

Lines 7 to 12 in 40cc2c4

	const isVisible: IsVisible = () => document.visibilityState === 'visible';
	/**
	* Whether the app is focused.
	*/
	const hasFocus: HasFocus = () => document.hasFocus();

When the user switches from Chrome/PWA to another macOS app, the NewDot tab is still visible, but the document is not focused. The current report list still runs this visible-only gate when a new action arrives in the open report:

App/src/pages/inbox/report/ReportActionsList.tsx

Lines 563 to 579 in 40cc2c4

	const handleReportChangeMarkAsRead = useCallback(() => {
	if (report.reportID !== prevReportID) {
	return;
	}
	const isLastActionUnread = lastAction && isCurrentActionUnread(report, lastAction, sortedVisibleReportActions);
	if (!isUnread(report, transactionThreadReport, isReportArchived) && !isLastActionUnread) {
	return;
	}
	// On desktop, when the notification center is displayed, isVisible will return false.
	// Currently, there's no programmatic way to dismiss the notification center panel.
	// To handle this, we use the 'referrer' parameter to check if the current navigation is triggered from a notification.
	const isFromNotification = route?.params?.referrer === CONST.REFERRER.NOTIFICATION;
	const isScrolledToEnd = scrollOffsetRef.current < CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD;
	if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
	readNewestAction(report.reportID, !!reportLoadingState?.hasOnceLoadedReportActions);

That calls readNewestAction(), which immediately advances lastReadTime:

App/src/libs/actions/Report/index.ts

Lines 2703 to 2727 in 40cc2c4

	function readNewestAction(reportID: string | undefined, hasOnceLoadedReportActions: boolean, shouldResetUnreadMarker = false) {
	if (!reportID) {
	return;
	}
	// Do not try to mark the report as read if the report has not been loaded and shared with the user.
	// However, if report actions already exist in Onyx (e.g., delivered via Pusher), the report is
	// clearly shared with the user and we can proceed with marking it as read.
	if (!hasOnceLoadedReportActions) {
	const reportActions = allReportActions?.[reportID];
	const hasReportActions = !!reportActions && Object.keys(reportActions).length > 0;
	if (!hasReportActions) {
	return;
	}
	}
	const lastReadTime = getDBTimeWithSkew();
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.COLLECTION.REPORT>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: `${ONYXKEYS.COLLECTION.REPORT}${reportID}`,
	value: {
	lastReadTime,
	},

The notification code already suppresses the current-report notification only when the app is both visible and focused, so that gate would not block this case:

App/src/libs/actions/Report/index.ts

Lines 4568 to 4572 in 40cc2c4

	// If we are currently viewing this report do not show a notification.
	if (reportID === topmostReportID && Visibility.isVisible() && Visibility.hasFocus()) {
	Log.info(`${tag} No notification because it was a comment for the current report`);
	return false;
	}

But after the premature read, the later "already read" guard drops the notification because lastReadTime >= action.created:

App/src/libs/actions/Report/index.ts

Lines 4589 to 4592 in 40cc2c4

	// If this notification was delayed and the user saw the message already, don't show it
	if (action && report?.lastReadTime && report.lastReadTime >= action.created) {
	Log.info(`${tag} No notification because the comment was already read`, false, {created: action.created, lastReadTime: report.lastReadTime});
	return false;

This only happens when the sender's report is the open report, because only that report action list advances the sender report's lastReadTime.

What changes do you think we should make in order to solve the problem?

In src/pages/inbox/report/ReportActionsList.tsx, require browser focus before auto-reading a newly received action in the open report:

if (((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
    readNewestAction(...);
}

Keep the notification-referrer exception, because clicking a notification can intentionally mark the report as read even when normal visibility/focus state is awkward.

Also wire the existing focus-return path to actual web window focus. The current handleAppVisibilityMarkAsRead callback already handles "the user came back and the unread message is in view", but a plain desktop app switch does not necessarily produce a visibility change. Use the existing useAppFocusEvent hook so the skipped read is performed when the NewDot window regains focus:

App/src/hooks/useAppFocusEvent/index.ts

Lines 9 to 17 in 40cc2c4

	const useAppFocusEvent: UseAppFocusEvent = (callback: UseAppFocusEventCallback) => {
	useEffect(() => {
	window.addEventListener('focus', callback);
	return () => {
	window.removeEventListener('focus', callback);
	};
	}, [callback]);
	};

Apply the same focus guard/focus-return handling to the parallel money-request report action list, which has the same visible-only immediate read condition:

App/src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx

Lines 339 to 359 in 40cc2c4

	useEffect(() => {
	if (!isFocused) {
	return;
	}
	if (isUnread(report, transactionThreadReport, isReportArchived) || (lastAction && isCurrentActionUnread(report, lastAction, visibleReportActions))) {
	// On desktop, when the notification center is displayed, isVisible will return false.
	// Currently, there's no programmatic way to dismiss the notification center panel.
	// To handle this, we use the 'referrer' parameter to check if the current navigation is triggered from a notification.
	const isFromNotification = route?.params?.referrer === CONST.REFERRER.NOTIFICATION;
	if ((isVisible || isFromNotification) && scrollingVerticalBottomOffset.current < CONST.REPORT.ACTIONS.ACTION_VISIBLE_THRESHOLD) {
	readNewestAction(report?.reportID, !!reportLoadingState?.hasOnceLoadedReportActions);
	if (isFromNotification) {
	Navigation.setParams({referrer: undefined});
	}
	} else {
	readActionSkipped.current = true;
	}
	}
	// eslint-disable-next-line react-hooks/exhaustive-deps
	}, [report?.lastVisibleActionCreated, transactionThreadReport?.lastVisibleActionCreated, report?.reportID, isVisible, reportLoadingState?.hasOnceLoadedReportActions]);

Scope boundaries:

• Touch the report-action list read gates and focus-return handling only.
• Do not loosen shouldShowReportActionNotification(); its focused-current-report and delayed-already-read checks are correct once lastReadTime is no longer advanced too early.
• No backend or API changes.

Add regression coverage for:

• visible + unfocused + scrolled to end: do not call readNewestAction immediately, so the notification is not suppressed as already read.
• visible + focused + scrolled to end: still mark read immediately.
• notification referrer: still marks read.
• window focus return after a skipped read: marks the visible in-view report read.

What alternative solutions did you explore? (Optional)

I considered changing the "already read" notification guard, but that guard is correct for delayed notifications after the user has genuinely read the message. The bad state is created earlier by the visible-only auto-read.

I also considered changing only the notification suppression check, but that would leave unread markers and lastReadTime wrong while the browser window is visible but unfocused.

[wildan-m]

🚫 Duplicated proposal withdrawn by 🤖 ProposalPolice.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @mananjadhav (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022061521168242779419

[github-actions]

⚠️ @wildan-m Your proposal is a duplicate of an already existing proposal and has been automatically withdrawn to prevent spam. Please review the existing proposals before submitting a new one.

[aswin-s]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On Web/Desktop, when NewDot is open with a chat as the active report and the user switches focus to another desktop app (the tab remains visible but unfocused), an incoming message in that chat produces no desktop notification and is silently marked as read. The notification only fires when a different chat is the open report.

What is the root cause of that problem?

The open-report auto-mark-as-read gate in handleReportChangeMarkAsRead is keyed on isVisible alone, not on window focus:

src/pages/inbox/report/ReportActionsList.tsx:578

if ((isVisible || isFromNotification) && !hasNewerActions && isScrolledToEnd) {
    readNewestAction(report.reportID, ...);
}

When the user switches to another desktop application (without minimizing or changing tabs), document.visibilityState === 'visible' but document.hasFocus() === false. isVisible is true, the gate passes, and readNewestAction advances report.lastReadTime to ≥ the incoming action's created.

Then the local-notification path is killed by the already-read guard in shouldShowReportActionNotification — src/libs/actions/Report/index.ts:4539:

if (action && report?.lastReadTime && report.lastReadTime >= action.created) {
    return false;
}

The sibling topmost-report suppression at Report/index.ts:4569 correctly requires Visibility.isVisible() && Visibility.hasFocus(), and the sibling handleAppVisibilityMarkAsRead in the same file (ReportActionsList.tsx:595) already gates on !isVisible || !isFocused. The bug is the weaker gate at line 578 — an internal inconsistency.

The same broken pattern exists at src/components/MoneyRequestReportView/MoneyRequestReportActionsList.tsx:349, so the same scenario silently consumes messages in money-request reports too.

What changes do you think we should make in order to solve the problem?

1. Tighten the gate in ReportActionsList.tsx:578 to also require window focus:

   if (((isVisible && Visibility.hasFocus()) || isFromNotification) && !hasNewerActions && isScrolledToEnd) {

   Read Visibility.hasFocus() imperatively here — do not reuse the component's existing isFocused (from useIsFocused), which is navigation focus and is true whenever the report is the active screen regardless of OS window focus.

2. Apply the identical fix in MoneyRequestReportActionsList.tsx:349 — same broken (isVisible || isFromNotification) gate, same effect. Without this, money-request reports keep the bug.

3. Wire focus-regain catch-up via the existing useAppFocusEvent hook (src/hooks/useAppFocusEvent/index.ts). visibilitychange doesn't fire on cross-app focus changes when the tab stays visible, so once focus returns to NewDot we need to re-run the mark-as-read path. Subscribing useAppFocusEvent to invoke handleAppVisibilityMarkAsRead (which already requires isVisible && isFocused) is the minimal addition; the same hook is already used by ReportLifecycleHandler.tsx for clearNotifications, so it's a known working analog.

4. No changes needed to shouldShowReportActionNotification — its isVisible() && hasFocus() gates are already correct; they were only being short-circuited by the premature lastReadTime advance.

5. Manual QA matrix: (a) focused tab — marks read immediately, no notification (current correct behavior, gate 4569); (b) visible-but-unfocused tab — does NOT mark read, notification fires; (c) hidden/minimized tab — does NOT mark read, notification fires (unchanged); (d) opened via notification (referrer === NOTIFICATION) — marks read regardless of focus (unchanged, isFromNotification branch preserved); (e) re-focus the tab while open — useAppFocusEvent catch-up marks the report read.

What alternative solutions did you explore? (Optional)

• Fix it inside shouldShowReportActionNotification by re-checking focus before the already-read gate. Rejected: lastReadTime would still be wrongly advanced in Onyx, leaving the chat marked read across the user's other clients even though they never saw it. The bug must be fixed at the mark-as-read site.
• Remove the isVisible-only branch and rely solely on handleAppVisibilityMarkAsRead. Rejected: that helper requires !hasNewMessagesInView || !hasUnreadReportAction semantics for the catch-up case and isn't the right shape for immediate read-on-arrival when the user is actually reading.
• Tighten only ReportActionsList.tsx and ignore the money-request variant. Rejected: same buggy pattern, same user-visible symptom in money-request reports.