desktest.net
GitHub

Web App Readiness Test Guide

A reference for the desktest.net Web App Readiness Test. This tool answers a narrow, practical question: will vendor web apps actually work in this browser? Not whether the browser is modern or up to date - that is the Browser Test - but whether the browser's configuration and policy settings let a real app sign in, stay signed in, alert the user, and copy and paste. Those are the settings that silently break Microsoft 365, ticketing, and chat apps on one workstation while an identical app works on the next desk over.

Open the Web App Readiness Test →

What does the Web App Readiness Test check?

Four capability probes that run end-to-end automatically. No hardware, no plugin, no permission prompts. Hit the button, wait about five seconds, read the verdict. Each probe targets a browser configuration or policy that can block a real vendor app even when the browser is modern and fully patched.

  1. Popups are allowed. Opens a tiny about:blank popup with window.open inside the run's click gesture, then closes it. Vendor sign-in flows (OAuth, SAML SSO, MFA re-auth) very often open a popup window; if the popup blocker or a policy kills it, sign-in silently fails.
  2. Cookies and site storage work. Round-trips a first-party cookie (SameSite=Lax), localStorage, and sessionStorage. Reports navigator.cookieEnabled. Adds a third-party-cookie capability signal (see below). Almost every login-based web app needs first-party storage to keep you signed in.
  3. Desktop notifications are available. Reports whether the Notification API exists and its current permission (granted, denied, or default). It never calls requestPermission(), so no prompt appears.
  4. Clipboard access works. Feature-detects navigator.clipboard, clipboard.writeText, clipboard.readText, and the legacy document.execCommand fallback. It reports capability only; it never reads the clipboard.

No network requests leave your browser; everything runs in JavaScript on the page. This tool is deliberately narrow: it does not re-check browser version, secure context, or general API support - that is the job of the Browser Test. Run both when onboarding a workstation.

When should I run this?

Reading the results

Each check gets a status badge: Pending, Running, Pass, Warn, or Fail. Fail and warn rows expand to show the 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 overall verdict is pass when popups, first-party storage, and clipboard are all fine; it drops to warn when something is merely restricted (third-party cookies partitioned, notifications blocked, clipboard partial) with a one-line likely cause; it is a fail when a core capability - popups, storage, or clipboard - is blocked outright.

Copy Diagnostic Report writes a plain-text report to the clipboard: origin, protocol, user agent, per-check status with a named diagnosis, the popup result, each storage round-trip, cookieEnabled, the third-party-cookie signal, notification support and permission, and the four clipboard capabilities. Paste it into a ticket.

The four checks, and how to fix each

Every failure path produces a specific named diagnosis. Each maps to a fix. Here they are, in the order the checks run.

popups-blocked: a sign-in popup could not open

The tool called window.open('about:blank', ...) from inside the button click and got back null, or a window that was immediately closed. That is exactly what happens to a vendor sign-in popup. Note that this test only works when the popup is opened synchronously inside a real user gesture - the tool does this deliberately, opening the popup first, before any other work, so the gesture is intact.

storage-blocked: cookies or web storage failed a round-trip

At least one of the first-party cookie, localStorage, or sessionStorage could not be written and read back. Web apps cannot keep you signed in without first-party storage. Common causes:

third-party-partitioned: third-party cookies are restricted (warn, not fail)

First-party storage works, but the browser exposes the Storage Access API (document.hasStorageAccess / document.requestStorageAccess), which means it partitions or restricts third-party cookies. This is reported as a warning, never a failure, because it does not break sign-in or normal app use - it breaks embedded vendor content: iframes and widgets that expect their own cookies to travel in a cross-site context. Those embeds may have to call requestStorageAccess(), and some older ones will simply break.

This is a capability signal, not a definitive per-vendor test. Whether a specific vendor's embedded content works depends on that vendor's own domain and cookies, which this tool never contacts. To test a real embed, load it on the vendor's own page. If you need to allow a specific third party, Chrome and Edge honor CookiesAllowedForUrls and the newer 3PCD / Related Website Sets and grace-period controls.

notifications-*: desktop notification permission

The tool reads Notification.permission without ever prompting. Three states:

clipboard-blocked / clipboard-partial: clipboard access

The tool feature-detects the clipboard write and read paths without reading anything.

For IT admins

The settings this tool probes are the usual suspects behind "the web app works on my machine but not on theirs." All of them are governable by policy; pin them once at the profile level instead of walking each user through browser settings.

Popups. Chrome and Edge: PopupsAllowedForUrls (in the chrome.admx / msedge.admx content-settings section). Add identity-provider and vendor sign-in origins rather than disabling the blocker globally. Firefox: dom.disable_open_during_load exceptions via policies.json.

Cookies and storage. Chrome / Edge: DefaultCookiesSetting, CookiesAllowedForUrls, CookiesBlockedForUrls. For embedded vendor content that needs third-party cookies during the phase-out, use CookiesAllowedForUrls and track Related Website Sets. Firefox: the Cookies policy key with Allow/Block lists. Avoid blanket third-party-cookie blocks on profiles that must run embedded vendor widgets.

Notifications. Chrome / Edge: DefaultNotificationsSetting, NotificationsAllowedForUrls, NotificationsBlockedForUrls. Set to Ask (not Block) so apps can prompt.

Clipboard. Chrome / Edge: DefaultClipboardSetting and the site-scoped clipboard permission. Kiosk and hardened images sometimes turn this off wholesale; if copy-paste is a requirement for the app, allow it for the app's origin.

Kiosk / VDI note. Locked-down profiles, in-app webviews, and some VDI browser stacks disable several of these at once (popups, clipboard, notifications) and may omit whole APIs. 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

Popup timing. The popup probe is the one check that is order-sensitive. Browsers only allow window.open to create a real window when it runs inside a live user-activation (the click). The tool therefore fires the popup first, synchronously, in the click handler - before any await - captures the result, and only then runs the asynchronous rest of the diagnostic. Opening the popup after an await would break the gesture chain and the browser would block it, producing a false failure. The window it opens is about:blank, 200x140, and it is closed immediately after the check.

Cookies and storage. The cookie probe sets a random-named cookie with SameSite=Lax; path=/ and reads document.cookie back, which catches partitioning cases where the cookie is silently scoped to a different partition than the document. localStorage and sessionStorage are each set, read, and removed. The third-party-cookie result is inferred from the mere presence of the Storage Access API (hasStorageAccess / requestStorageAccess) - its existence tells you the browser partitions third-party cookies. This is honest as a capability signal only; a real third-party-cookie test needs the vendor's own domain, which the tool never contacts.

Notifications and clipboard. Both are read with plain typeof / in checks and property reads. The tool never calls Notification.requestPermission() and never calls navigator.clipboard.readText(), because both would trigger a permission prompt or require a gesture. It reports only what is exposed and what the current permission already is.

Nothing leaves the browser. All probes run 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 for browsers that block clipboard write. View source to verify.

Elsewhere on the web: