desktest.net
guide

Browser Test Guide

A reference for the desktest.net Browser Test. Explains what the tool checks, how to read the verdict, and what to do about each failure. Useful before installing a vendor SaaS app on a new workstation or before spending an hour on a ticket that turns out to be an out-of-date browser.

Open the Browser Test ->

What does the Browser Test check?

Three feature-detection probes that run end-to-end automatically. No hardware, no plugin, no clicks during the run. Hit the button, wait about five seconds, read the verdict.

  1. Browser identification, version, and system info. Prefers navigator.userAgentData, falls back to navigator.userAgent parsing. Classifies brand, engine, and major version against the minimum recommended for common business SaaS. Also reads platform, language, hardwareConcurrency, deviceMemory, and the Network Information API when exposed.
  2. Security context and storage availability. Reads window.isSecureContext, then round-trips a first-party cookie, localStorage, and sessionStorage. Probes IndexedDB, BroadcastChannel, and crypto.subtle. Almost every login-based web app needs these.
  3. Modern web API support matrix. Feature-detects nineteen APIs: WebSocket, fetch, AbortController, Promise, async/await, the three observers, matchMedia, CSS.supports, getComputedStyle, requestIdleCallback, ServiceWorker, WebRTC, Web Audio, Storage Manager, Push API, Notifications, and Clipboard. Each is flagged critical or optional.

No network requests leave your browser; everything runs in JavaScript on the page.

When should I run this?

Reading the results

Each step gets a status badge: Pending, Running, Pass, Warn, or Fail. Fail and warn rows expand to show the meta 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. It is opinionated: it reflects the most common real-world reason for each failure. If the verdict is wrong for your case, the expanded fix block under the failing row covers the rest.

Copy Diagnostic Report writes a plain-text report to the clipboard: browser, engine, minimum supported version, platform, language, CPU cores, device memory, Network Information API output, full user agent, origin, protocol, secure context, per-step status with diagnosis, per-storage round-trip detail, and the full feature matrix. Paste it into a ticket.

Common failures and fixes

The tool produces a specific named diagnosis for every failure path. Each diagnosis maps to a fix. Here they are, in the order the steps run.

browser-too-old: below the minimum recommended version

Major version is below the baseline for common business SaaS: Chrome 100+, Edge 100+, Firefox 100+, Safari 15+, Opera 85+, Brave 100+. Internet Explorer and legacy EdgeHTML Edge always fail.

insecure-context: page is not in a secure context

window.isSecureContext returned false. Almost every modern web API requires a secure context: Web Crypto, ServiceWorker, Clipboard write, the new permissions model, partitioned storage. Usually one of:

http://localhost and http://127.0.0.1 are treated as secure contexts by every current browser. If you are testing locally on loopback, you do not need a real cert. Remote http origins do not get that pass.

storage-disabled: cookies, localStorage, or IndexedDB blocked

The page is secure, but at least one of cookies, localStorage, or IndexedDB failed a round-trip. Web apps cannot keep you logged in without these. Common causes:

missing-critical-api: critical web APIs missing

The browser version is recent enough to pass step 1 but the JavaScript engine is missing one or more of: WebSocket, fetch, AbortController, Promise, async/await, IntersectionObserver, or matchMedia. Usually only happens on very old browser engines, embedded Chromium webviews from old Electron / CEF builds, or kiosk shells that ship a frozen runtime. Update or replace the browser. If this is an in-app webview, open the page in the system browser instead.

limited-modern: optional APIs missing

All critical APIs passed. One or more optional APIs are missing, marked as a warn rather than a fail. The most common case is Safari, which historically does not implement requestIdleCallback; older Safari also lags on Storage Manager and parts of the Clipboard API. Most business apps will still work. Note this only if a specific app reports a related error.

unknown-browser: brand not identified

The user agent did not match any of the known brand patterns. Could be a niche browser, a webview embedded in a desktop app, a corporate browser based on a stripped-down Chromium, or a UA override extension. Check the browser's About dialog for the real brand and version. If this is a kiosk shell or in-app webview, open the page in the system browser before re-testing.

For IT admins

Browser version is the single most common root cause of "the web app does not work." Pin it once at the workstation image level, then enforce updates through policy rather than asking users to click through update prompts.

Chrome on Windows: the chrome.admx templates ship with Google Chrome Bundle for Enterprise. The relevant policies are UpdateDefault, AutoUpdateCheckPeriodMinutes, and the per-app BrowserUpdateGroupPolicy (Chrome's GUID is {8A69D345-D564-463c-AFF1-A69D9E530F96}). Set update default to "Always allow updates" and rollout target version to latest. Roll back through the policy if a release breaks a vendor app, do not freeze.

Edge on Windows: the msedge.admx templates expose the equivalent Edge Update Policies (UpdateDefault, TargetChannel, InstallDefault). Edge follows the same Chromium release cadence. Pin to the Extended Stable channel if you need a slower cycle.

Firefox: use policies.json at %PROGRAMFILES%\Mozilla Firefox\distribution\policies.json or the Mozilla ADMX. Set DisableAppUpdate=false and AppAutoUpdate=true. Use the ESR channel for slower rollout.

Common version-pin rationale and risks: teams pin browsers to dodge regressions from rapid Chromium updates. The risk is the opposite: vendor SaaS apps drop support for browsers older than 12 months. A pin that started as "stability" turns into the reason the workstation cannot log into the new core banking platform. Track the vendor's supported-browsers matrix and rotate the pinned version on a known cadence, not "when it breaks."

Citrix / RDS / VDI: a browser running inside a Citrix XenApp or RDS session sees the session's video, audio, and storage stack, not the local thin client's. Hardware-acceleration features (WebGL, WebRTC video) often degrade or fall back to software. The Browser Test will still pass the feature-detection probes because the APIs are present, but real-world performance for video-heavy or 3D-heavy apps will be much worse than on a local install. For Citrix specifically, use the Citrix Workspace Browser Content Redirection feature where the vendor supports it.

Behind the scenes

Step 1 prefers navigator.userAgentData because it is structured and not subject to UA reduction. userAgentData is Chromium-only (Chrome, Edge, Opera, Brave, Chromium). For Safari, Firefox, and older Chromium without UA Client Hints, the tool falls back to navigator.userAgent string parsing with the standard ordering: Edg/, OPR/, Firefox/, Chrome/ (excluding Chromium/), Chromium/, then Safari Version/ guarded by the Safari token to avoid false matches on every Chromium browser.

Step 2 checks window.isSecureContext rather than just location.protocol === 'https:' because the platform's secure-context rules also accept loopback addresses and any local-only origins the user agent decides to trust. The cookie probe sets SameSite=Lax with path=/ and then reads document.cookie back: this catches storage-partitioning cases where the cookie is silently scoped to a different partition than the document. Web Crypto is checked through window.crypto.subtle.digest because crypto.subtle is only exposed in secure contexts; a missing subtle almost always means the secure context check has already failed.

Step 3 uses simple typeof and in checks rather than calling each API. This avoids permission prompts (Notifications, Clipboard read), avoids triggering ServiceWorker registration, and avoids creating AudioContexts that the browser then suspends until a user gesture. The feature matrix marks WebSocket, fetch, AbortController, Promise, async/await, IntersectionObserver, and matchMedia as critical and the remaining twelve as optional, because every modern business web app needs the seven criticals to function at all.

The Storage Manager API (navigator.storage.estimate()) is feature-detected but not called. The estimate result varies wildly across browsers and is not part of the verdict. If you need real-world quota numbers for capacity planning, query it from a script of your own; the Browser Test will not.

Nothing leaves the browser. All probes run in JavaScript on the page. View source to verify. 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.