[$250] Web - Notifications - App doesn't display notification on Edge Browser

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.4.6-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: https://test-management.browserstack.com/projects/2219752/test-runs/TR-42186/folder/13176925/41237591/1481941714?sort=%2Bidentifier
Email or phone of affected tester (no customers): leungbratt6sadadad@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Windows 10/Chrome/Edge
App Component: Notifications

Action Performed:

Preconditions: 2 users log in 2 browsers, Chrome and Edge

1. Open the user on Edge -> enter some chat in the 1:1
2. Open the user on Chrome -> enter some chat in the 1:1 same chat

Expected Result:

Edge browser displays the notification ( I tried with Chrome, Firefox, Brave, which display the notification)

Actual Result:

Edge browser doesn't display the notification only sound

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7179059_1781279536450.noti_edge_2.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Svetlana Lazutkina
Bug ID: 7179059

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022065476834283521311
• Upwork Job ID: 2065476834283521311
• Last Price Increase: 2026-06-12

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/0ee91838a8245f5a3e030df54468fddcbfbc733646f61a19264c92e159a4c33c

[MelvinBot]

Issue Analysis

Root Cause (Medium confidence): This is most likely a Windows/Edge notification setting, not an App bug. The App plays the notification sound itself (via Howler/HTML5 audio), completely decoupled from the OS-displayed banner. So "sound plays but no banner on Edge" is exactly the symptom you get when Edge's banners are suppressed at the OS level while the App's own audio keeps firing.

Evidence chain:

• BrowserNotifications.ts:58-67 constructs the notification with silent: true, then separately calls playSound(SOUNDS.RECEIVE). The banner is handled by the OS; the sound is handled by the App.
• Sound/index.ts:31-43 plays the sound through Howler (web audio), which is unaffected by OS notification banner settings.
• The exact same standard Web Notification API code path runs on Chrome, Firefox, Brave, and Edge. Since the App code does not branch per-browser, a differential where only Edge hides the banner points to a browser/OS-level configuration rather than App logic.

Recommended next step (verify before treating as a code bug): On the affected Windows machine, check Settings → System → Notifications → Microsoft Edge and confirm "Show notification banners" is enabled, and that Focus assist / Do not disturb is off. Also confirm Edge's own site notification setting for the app is set to allow (not "quiet"). If banners are disabled there, the sound-only behavior is expected and is not fixable from App code.

Investigation details & alternatives considered

• Could it be the empty tag? pushReportCommentNotification passes tag = '' (default). An empty tag is valid in the Notification spec and does not suppress display in Edge, so this is unlikely.
• Service-worker requirement? Desktop Edge supports the non-persistent new Notification() constructor used here, so a missing service worker is not the cause on desktop.
• Why sound but no banner is the tell: if this were an App-side failure to create the notification, you'd expect an exception or no sound either — but the sound is fired unconditionally after the Notification is constructed, independent of whether the OS actually surfaces a banner.
• This was reproduced by Applause on Windows 10 / Edge only; Chrome on the same flow works, which is consistent with a per-app Windows notification setting rather than App code.

If a verified-correct Windows notification config still shows no Edge banner, this would warrant a deeper look at Edge-specific Notification API behavior — but there is no evidence of an App code defect at this point.

---

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

[aswin-s]

Proposal

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

On Windows Edge, when a user receives a new chat message, the App plays the notification sound but does not display the visible browser notification banner. Chrome, Firefox, and Brave on the same OS display the banner correctly. Expected behavior: Edge should display the notification banner alongside the sound.

What is the root cause of that problem?

In src/libs/Notification/LocalNotification/BrowserNotifications.ts:62, the Notification constructor is called with silent: true so the browser's built-in notification sound is suppressed and the app can play its own custom sound via playSound(SOUNDS.RECEIVE) on line 66. Microsoft Edge (Chromium) treats silent: true more aggressively than other Chromium-based browsers — it suppresses the visual toast/banner along with the sound, so only the app's custom sound plays. Chrome/Firefox/Brave still show the visible toast when silent: true is set, which is why the bug only reproduces on Edge.

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

1. src/libs/Notification/LocalNotification/BrowserNotifications.ts:58-67 — Stop passing silent: true to the Notification constructor unconditionally. Instead, drive the silent option from the existing silent parameter that push() already accepts (line 48), so the platform plays its own sound when we don't want a custom one, and the custom playSound path is used only when both flags align.
2. To preserve the existing custom-sound UX without double-playing on Edge, detect Edge via navigator.userAgent (contains Edg/) and, on Edge only, omit silent: true and skip the manual playSound(SOUNDS.RECEIVE) call — letting Edge surface its native toast + sound. Other browsers keep the current custom-sound behavior.
3. Add a brief inline comment near line 62 documenting the Edge-specific behavior so the workaround isn't reverted later.
4. Verify on Edge that pushReportCommentNotification, pushModifiedExpenseNotification, and pushUpdateAvailableNotification all surface a visible toast after the change (they all funnel through the single push() helper, so one fix covers all three).

What alternative solutions did you explore? (Optional)

Drop silent: true for all browsers and remove the custom playSound — simplest, but loses the custom RECEIVE sound on Chrome/Firefox where it currently works.

[ahmdshrif]

Proposal

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

On Microsoft Edge, an incoming chat message plays the notification sound but never shows the visual notification banner. Chrome, Firefox and Brave all display the banner correctly.

What is the root cause of that problem?

1. Every browser notification is built in push() with the silent option hardcoded to true, ignoring the silent parameter that callers pass:
   

   App/src/libs/Notification/LocalNotification/BrowserNotifications.ts

   Lines 58 to 63 in 91b6a3f

   	notificationCache[notificationID] = new Notification(title, {
   	body,
   	icon: SafeString(icon),
   	data,
   	silent: true,
   	tag,

2. The audible cue the tester hears does not come from the browser notification — it comes from a separate in-app playSound(SOUNDS.RECEIVE) call that runs whenever the notification is not silent:
   

   App/src/libs/Notification/LocalNotification/BrowserNotifications.ts

   Lines 65 to 67 in 91b6a3f

   	if (!silent) {
   	playSound(SOUNDS.RECEIVE);
   	}

3. pushReportCommentNotification always calls push() without a silent argument, so silent defaults to false and the manual sound always plays — yet the Notification itself is still created with silent: true:
   

   App/src/libs/Notification/LocalNotification/BrowserNotifications.ts

   Lines 99 to 127 in 91b6a3f

   	const icon = usesIcon ? EXPENSIFY_ICON_URL : '';
   	const isRoomOrGroupChat = ReportUtils.isChatRoom(report) || ReportUtils.isPolicyExpenseChat(report) || ReportUtils.isGroupChat(report);
   	const {person, message} = reportAction;
   	const plainTextPerson = person?.map((f) => Str.removeSMSDomain(f.text ?? '')).join() ?? '';
   	// Specifically target the comment part of the message
   	let plainTextMessage = '';
   	if (Array.isArray(message)) {
   	plainTextMessage = getTextFromHtml(message?.find((f) => f?.type === 'COMMENT')?.html);
   	} else {
   	plainTextMessage = message?.type === 'COMMENT' ? getTextFromHtml(message?.html) : '';
   	}
   	if (isRoomOrGroupChat) {
   	const roomName = getReportName(report, reportAttributes);
   	title = roomName;
   	body = `${plainTextPerson}: ${plainTextMessage}`;
   	} else {
   	title = plainTextPerson;
   	body = plainTextMessage;
   	}
   	const data = {
   	reportID: report.reportID,
   	};
   	push(title, body, icon, data, onClick);

A silent: true web notification is treated by Edge on Windows as a low-priority/muted toast and is dropped from the banner surface, whereas Chromium-on-Chrome, Firefox and Brave still render it. So on Edge the only feedback left is the independent playSound call — which is precisely the reported symptom: "doesn't display the notification, only sound".

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

Stop hardcoding silent: true and let the notification respect the actual flag, so the banner is shown on every browser including Edge:

notificationCache[notificationID] = new Notification(title, {
    body,
    icon: SafeString(icon),
    data,
    silent,   // was: silent: true
    tag,
});

Because the manual playSound already plays our custom sound for non-silent notifications, we should drop that redundant playSound block and rely on the browser's own (now non-silent) notification sound, keeping a single source of truth and avoiding a double sound. This only changes the silent flag/sound source — title, body, icon, click handling, caching and the silent-param callers (e.g. update-available) are untouched.

What alternative solutions did you explore? (Optional)

• Keep playSound and keep the notification non-silent: shows on Edge but plays two sounds on Chromium — rejected.
• Browser-sniff Edge and only drop silent: true there: fragile UA detection for a flag that has no reason to be forced — rejected.
• Move to Service-Worker showNotification with a custom sound: correct long-term but far larger than this regression warrants — rejected.

[lorretheboy]

Proposal

What is the root cause of that problem?

The browser Notification is always constructed with silent: true, and the app plays its own sound separately via playSound(SOUNDS.RECEIVE):

App/src/libs/Notification/LocalNotification/BrowserNotifications.ts

Lines 58 to 67 in 91b6a3f

	notificationCache[notificationID] = new Notification(title, {
	body,
	icon: SafeString(icon),
	data,
	silent: true,
	tag,
	});
	if (!silent) {
	playSound(SOUNDS.RECEIVE);
	}

This was introduced to replace the OS default notification sound with a custom one (commit beea03f, "Have no sound for notification received").

On Windows, Edge routes web notifications through the Windows Action Center, and a silent: true notification is treated as "deliver quietly" → it is dropped into the Action Center without a popup banner. Chrome/Firefox/Brave still pop the banner for silent notifications, which is why only Edge is affected. So on Edge the chain is: silent: true → Windows suppresses the toast banner → user sees nothing, but still hears the manually-played playSound. That exactly matches the report ("doesn't display the notification only sound").

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

Stop hard-coding silent: true. Pass the function's silent argument through to the Notification and let the browser render its native banner (with its own sound), removing the separate playSound call:

App/src/libs/Notification/LocalNotification/BrowserNotifications.ts

Lines 56 to 67 in 91b6a3f

	// We cache these notifications so that we can clear them later
	const notificationID = Str.guid();
	notificationCache[notificationID] = new Notification(title, {
	body,
	icon: SafeString(icon),
	data,
	silent: true,
	tag,
	});
	if (!silent) {
	playSound(SOUNDS.RECEIVE);
	}

i.e. use silent (the param) in the constructor options and drop the if (!silent) { playSound(...) } block. Report-comment notifications already call push with silent defaulting to false, so the banner reappears on Edge. This restores correct visual behavior on Edge while remaining unchanged on Chromium/Firefox.

What alternative solutions did you explore? (Optional)

If keeping the custom SOUNDS.RECEIVE sound is a hard requirement, detect Edge/Windows (e.g. getBrowser/user-agent) and only force silent: true on browsers that still show the banner for silent notifications, keeping silent: false (native banner + sound) on Edge. This is more complex and brittle than simply relying on the browser's native notification, so the primary fix above is preferred.

[melvin-bot]

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

[melvin-bot]

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

[godzillaxbox19982014-lgtm]

Proposal

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

Web - Notifications - App doesn't display notification on Edge Browser

What is the root cause of that problem?

I traced this to the path that handles iOS:

• src/pages/inbox/report/useShouldShowEnableNotificationsBanner.ts:15 (isConcierge): const isConcierge = isConciergeChatReport(report, conciergeReportID);
• src/pages/inbox/report/EnableNotificationsBanner.tsx:60 (EnableNotificationsBanner): EnableNotificationsBanner.displayName = 'EnableNotificationsBanner';
• src/pages/inbox/report/EnableNotificationsBanner.tsx:19 (EnableNotificationsBanner): paddingBottom: BANNER_VISIBLE_BOTTOM_GAP_PX + BANNER_COMPOSER_OVERLAP_PX,
• The local evidence matches this recurring failure shape: the composer visibility gate and recipient lookup are derived from different Onyx selector states. Here, src/pages/inbox/report/useShouldShowEnableNotificationsBanner.ts:15 and src/pages/inbox/report/EnableNotificationsBanner.tsx:60 do not agree on the same iOS value, so the user-visible path can show a missing or stale state even though nearby data already has the needed context.

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

• Update src/pages/inbox/report/useShouldShowEnableNotificationsBanner.ts:15 to derive iOS from the report/transaction source that owns this flow before the value is consumed.
• Carry the same normalized value through src/pages/inbox/report/EnableNotificationsBanner.tsx:60; that follows the safer family move to derive the recipient accountID once, then let both the eligibility selector and recipient selector use that same ID, so the write/optimistic/read paths agree instead of only changing the visible component.
• Keep the change inside the Chat Report, Composer, Recipient Local Time surface and avoid changing chat composer rendering, Onyx selector churn.

What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?

1. Add or update a regression in tests/unit/ComposerLocalTimeTest.tsx for the exact issue flow: Web - Notifications - App doesn't display notification on Edge Browser.
2. Cover the counter-case near src/pages/inbox/report/useShouldShowEnableNotificationsBanner.ts:15 so valid existing iOS behavior still works.
3. Manually repeat the issue steps after the patch and confirm the visible state/action is no longer stale.

What alternative solutions did you explore? (Optional)

• I would not add a broad new condition outside these referenced paths; the safer fix is to keep iOS consistent at the first read/write boundary shown above.