desktest.net
GitHub

Screen Share Test Guide

A reference for the desktest.net Screen Share Test. Explains what the tool checks, how to read the verdict, and what to do about each failure. Useful before a Teams, Zoom, or Meet screen-share, or when a "cannot share my screen" ticket lands and you need to know in fifteen seconds whether it is the browser, an OS permission, or a remote-session limitation.

Open the Screen Share Test →

What does the Screen Share Test check?

Three steps, in order. Step 1 runs automatically; step 2 needs one click (the browser only opens the "choose what to share" picker in response to a real user gesture); step 3 is derived from the same capture.

  1. Screen capture is supported. Feature-detects navigator.mediaDevices.getDisplayMedia and reports window.isSecureContext. If the API is missing the step fails: the browser is very old, the page is not in a secure context, or a policy disabled screen capture.
  2. You can pick and share a source. A Start screen share test button calls getDisplayMedia({video:true, audio:true}). When you pick a screen, window, or tab, the stream is attached to a small muted local preview. The tool reads the video track settings (width, height, frameRate, and displaySurface from track.getSettings()), confirms frames are actually flowing, then stops every track after a few seconds or when you click Stop.
  3. System audio can be shared (optional). From the same capture, the tool reports whether an audio track came along (getAudioTracks().length). System-audio support varies widely, so this is informational and never a hard fail.

The captured stream never leaves this tab. It is shown only in the local preview, is never recorded or transmitted, and every track is stopped the moment the test ends. No network requests leave your browser.

When should I run this?

This tool is deliberately distinct from the WebRTC Test, which checks the peer connection that carries the call. Screen sharing can work perfectly here while a call still fails on the network side, and vice versa. Run both when a screen-share problem could be either the capture or the connection.

Reading the results

Each step 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. It is opinionated: it reflects the most common real-world reason for each outcome. A cancelled or policy-blocked capture is a warning, not a failure, because the machine is capable of sharing once the picker is used or the policy is relaxed. A missing system-audio track never drags the verdict down: the core question, "can this machine share its screen," is still yes.

Copy Diagnostic Report writes a plain-text report to the clipboard: browser, platform, origin, secure context, per-step status with diagnosis, the shared surface, resolution, negotiated frame rate, the frame-confirmation sample, and whether a system-audio track was present. It never contains any pixels. Paste it into a ticket.

Common failures and fixes

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

Step 1 fails: screen capture is not supported

The browser does not expose getDisplayMedia. Two usual causes, both shown in the step detail:

cancelled-or-blocked: no source was shared (warning)

getDisplayMedia threw NotAllowedError. The browser cannot tell "the user dismissed the picker" apart from "a policy blocked the request," so both land here as a warning. Work through it in this order:

no-frames / no-video-track: shared, but no frames arrived

The capture session started but the preview never produced frames (videoWidth stayed 0). This is a GPU, driver, or remote-session limitation, not a permission problem.

capture-failed: the capture would not start

getDisplayMedia rejected with something other than NotAllowedError (for example NotReadableError or NotFoundError). The exact errorName is in the step detail and the report. Retry, update the browser to the current version, and confirm the OS grants the browser screen-recording permission.

System audio not shared (informational)

The capture returned video only, shown as a warn on the optional audio row. This is expected on most setups and does not mean the screen cannot be shared. What can and cannot carry system audio:

BrowserSystem / screen audioNotes
Chrome / EdgeYes, with a tickTab audio when sharing a tab; whole-screen / system audio when you tick "Share system audio" in the picker. Best on Windows and ChromeOS; limited on macOS.
FirefoxLimitedScreen sharing works; system-audio capture is limited or unavailable depending on version and OS.
SafariNoShares video only; does not capture system audio.

If a call needs the audience to hear a video you are sharing, use Chrome or Edge, share a browser tab (or the whole screen with the audio box ticked), and confirm this row reads Pass.

For IT admins

Screen sharing failures cluster around three root causes: the OS permission, the browser policy, and the session type (local versus remote). Handle each at the image level.

macOS Screen Recording (TCC): every browser must be granted Screen Recording in System Settings then Privacy & Security before it can call getDisplayMedia successfully. This lives in the TCC database and can be pre-seeded with an MDM Privacy Preferences Policy Control (PPPC) profile that grants ScreenCapture to the browser bundle IDs (com.google.Chrome, com.microsoft.edgemac, org.mozilla.firefox, com.apple.Safari). Without the profile, users hit the permission wall on first share and after some OS updates.

Chrome / Edge policy: the ScreenCaptureAllowed policy (and the finer-grained ScreenCaptureAllowedByOrigins, WindowCaptureAllowedByOrigins, TabCaptureAllowedByOrigins, SameOriginTabCaptureAllowedByOrigins) controls whether the browser may share at all and which surfaces are offered. If screen sharing is silently unavailable on managed machines, check these first. Leaving ScreenCaptureAllowed unset defaults to allowed.

Firefox policy: screen sharing is governed by the standard permission model rather than a dedicated allow/deny policy; the usual lever is the site-permission prompt plus the OS-level (macOS) grant. Use policies.json for permission defaults where you must.

RDP / Citrix / VDI: a browser inside a remote session captures the session's virtual framebuffer, not the local endpoint. Results range from working, to low frame rate, to a blank stream, depending on the broker and GPU virtualization. Where the collaboration vendor supports it, offload the call to the endpoint with the Citrix / VMware / AVD optimization pack (for Teams, the media-optimization plug-in) so screen sharing runs on the local machine instead of inside the session. The Screen Share Test run inside the session reflects what the session can do; run it on the endpoint too to compare.

Permissions-Policy and iframes: getDisplayMedia is gated by the display-capture Permissions Policy, whose default allowlist is self. A top-level same-origin page shares fine by default. A cross-origin iframe that needs to share must be granted allow="display-capture" by its parent, or the call throws.

Behind the scenes

Step 1 is a pure feature-detection: it checks that navigator.mediaDevices exists and that navigator.mediaDevices.getDisplayMedia is a function, and records window.isSecureContext. Nothing is requested, so there is no prompt and no gesture needed.

Step 2 must run getDisplayMedia from a real user gesture, so it is deliberately gated behind the Start button rather than firing on page load. The call requests {video:true, audio:true}; the browser decides what surfaces and whether an audio checkbox to offer. On success the tool reads track.getSettings() for width, height, frameRate, and displaySurface (monitor, window, or browser). To prove frames are genuinely flowing rather than just that metadata loaded, it counts presented frames with requestVideoFrameCallback where available, and otherwise confirms the video's currentTime advanced. Screen-share frame rates are legitimately low when the shared surface is static, so a low rate is reported but never failed.

The preview uses video.srcObject = stream, which attaches the live MediaStream object directly rather than loading a URL, so it works under the page's strict Content-Security-Policy with no media-src grant. The element is muted and playsinline so playback needs no second gesture.

When the sample window ends (after a few seconds, on a Stop click, or when you end the share from the browser's own bar), every track is stopped with track.stop(). That clears the OS "sharing your screen" indicator immediately and releases the source for the real call. The same stop runs on Reset and on page unload.

No pixels are ever read or recorded. The tool never draws the video to a canvas and never uploads anything. The report contains only the surface type, resolution, negotiated frame rate, the frame-confirmation counters, and whether an audio track was present. Everything runs in JavaScript on the page; view source to verify.

Elsewhere on the web: