DeskTest.net
GitHub

Notification Test Guide

A reference for the DeskTest.net Notification Test. This tool answers a narrow, practical question: when an app tries to show a desktop notification, does one actually appear on this machine? It is the tool to reach for on the "my Teams alerts never pop up" or "browser notifications do nothing" ticket. Unlike the notification row in the Web App Readiness Test, which only reads the permission state, this tool requests permission and fires a real test notification end to end.

Open the Notification Test →

What does the Notification Test check?

Two steps that run when you click the button. No hardware, no plugin. Your browser may show a permission prompt; choose Allow.

  1. Notifications are supported. Confirms the Notification API exists in this browser and that the page is a secure (HTTPS) context, then reads the current Notification.permission (granted, denied, or default). Kiosk shells and in-app webviews sometimes omit the API entirely.
  2. Permission is granted and a test notification fires. Calls Notification.requestPermission() - this is what triggers the browser prompt - and, if you allow it, constructs a real new Notification('desktest.net test', ...) and shows it on your desktop. It confirms the notification was created without error and listens for the browser's show event, then closes the notification automatically after a few seconds.

No network requests leave your browser. The only thing that leaves the page is the single desktop notification you asked for, which auto-closes. View source to verify.

Nothing sensitive is shown. The test notification contains fixed text (desktest.net test) and no personal data, so it is safe to run on any workstation, including in front of a user on a ticket.

When should I run this?

Reading the results

Each step gets a status badge: Pending, Running, Pass, Warn, or Fail. Warn and fail rows expand to show a detail dump and a numbered fix list.

The verdict panel at the top gives a one-line title, a likely cause, and a recommended next step. The three outcomes it distinguishes map directly to where the problem is: notifications work (a test notification was displayed), blocked in this browser (permission denied - re-allow it), or the OS is suppressing them (permission is granted but nothing showed - Focus Assist / Do Not Disturb, or a focused tab).

Copy Diagnostic Report writes a plain-text report to the clipboard: origin, secure-context flag, user agent, per-step status with a named diagnosis, the permission state after the request, whether the tab was focused, and whether the notification was created and confirmed shown. Paste it into a ticket.

The verdicts, and how to fix each

Every outcome produces a specific named diagnosis. Each maps to a fix.

notifications-unsupported: the API is missing

The Notification API is not present in this browser, or the page is not a secure context. There is nothing on the page to fix. Kiosk shells, in-app webviews (a browser embedded inside another app), and some stripped-down browser builds omit the API. Open the app in a full desktop browser - Chrome, Edge, Firefox, or Safari - over HTTPS, and run the test again.

notification-shown: notifications work (pass)

Permission is granted and the browser confirmed the test notification was displayed. Notifications work at the browser and OS level. If a specific app still does not alert you, the problem is inside that app: check that the app itself has notification permission (both in the app's own settings and in the OS per-app notification list), and that the OS is not in Do Not Disturb.

permission-denied: blocked in this browser (fail)

Permission is denied, so no notification can be shown. This is the "blocked in this browser" verdict. Re-allow it:

permission-dismissed: no decision made (warn)

The permission is still at its default state - the prompt was dismissed or ignored, or the browser suppressed it (some browsers show a quieter prompt or stop asking after the prompt has been dismissed a few times). Run the test again and click Allow, or set Notifications to Allow from the address bar site settings first.

shown-unconfirmed: granted, but display not confirmed (warn)

Permission is granted and the notification was created without error, but the browser did not fire its show event within the test's wait window. If you saw the popup, notifications are working - some browsers (notably Firefox) never fire this internal signal even when the notification did appear, so this warning can be a false alarm. If you did not see it, the operating system is almost certainly suppressing it. See the next section.

fire-error: the notification could not be created (fail)

Permission is granted but constructing the notification threw an error. This usually means the OS is blocking notifications for the browser entirely, or a Focus / Do Not Disturb mode is fully suppressing them. Enable notifications for the browser in the OS settings, turn off Focus Assist / Do Not Disturb, and run the test again.

"Granted but nothing appeared": OS suppression

This is the case that trips people up. The browser has permission and posts the notification successfully, but no banner appears on screen. The browser has done its job; something below it is swallowing the popup. In order of likelihood:

Why the browser cannot just tell you. The Focus Assist / Do Not Disturb state is an operating-system setting that is deliberately not exposed to web pages. So when permission is granted and the notification is posted without error, the browser genuinely believes it succeeded - it has no way to know the OS silently dropped the banner. That is why this tool hedges: it reports what it can prove (permission and a clean construct) and points you at the OS settings that account for the rest.

For IT admins

Notification failures split cleanly into three layers; fix the lowest one that is broken.

Browser permission. Chrome / Edge: DefaultNotificationsSetting (set to 2 = Ask, not 3 = Block), NotificationsAllowedForUrls, NotificationsBlockedForUrls. Firefox: the Permissions → Notifications policy with Allow / Block origin lists. Pin the app's origin to Allow so users never see a prompt.

OS notification settings. Notifications must be enabled for the browser at the OS level, above any per-site browser permission. On Windows this is Settings → System → Notifications and the per-app entry for the browser; via policy, the ToastEnabled and Focus Assist / Do Not Disturb settings are manageable through Group Policy / MDM. On macOS, the per-app notification allowance and banner style are in System Settings → Notifications and can be pushed via a configuration profile.

Focus Assist / Do Not Disturb. Automatic rules (during certain hours, while duplicating the display, while a full-screen app runs) enable suppression without user action and are the single most common "granted but nothing shows" cause on managed Windows fleets. Review the automatic-rules policy for the image.

Kiosk / VDI note. Locked-down profiles, in-app webviews, and some VDI browser stacks disable or omit notifications entirely. Run this tool on the actual profile the users get, not on your admin workstation, or the result will not match what they experience.

Behind the scenes

Gesture timing. Some browsers (Safari) only honor Notification.requestPermission() when it is called inside a user gesture. The tool therefore fires the request synchronously in the button's click handler, before any other asynchronous work, and consumes the result a moment later - the same pattern the Web App Readiness Test uses to open its popup inside the gesture. The request is normalized across the modern promise form and the legacy callback form.

Firing and confirming. On a granted permission the tool constructs new Notification('desktest.net test', { body, tag, requireInteraction:false }). It wires onshow (to confirm display), onerror (to catch a construct-time failure), and onclick (which focuses the window and closes the notification). It waits about 1.4 seconds for the show event, then reports; a missing show is treated as "not confirmed", never as a definite failure, because show is unreliable across browsers. The notification is closed automatically after a few seconds, and both timers and the notification object are torn down on Reset.

Nothing leaves the browser. All logic runs in JavaScript on the page. There are no network requests. The diagnostic report is plain text built in memory and copied to the clipboard via navigator.clipboard.writeText with a synthetic textarea fallback. The only external effect is the single OS notification you requested.

Elsewhere on the web: