Clipboard Test

Introduction

The DeviceHub Clipboard Test is a free online smoke test for Async Clipboard write and optional read paths triggered by explicit button clicks on secure HTTPS, so you can see whether copy-to-clipboard flows work in your profile without assuming silent access on page load. Developers validating Copy link buttons, IT checking hardened environments, and support reproducing paste failures use gesture-driven probes because clipboard APIs intentionally reject many calls without user activation. DeviceHub lists typed permissions as none because this metadata model records pre-granted Privileged Permissions API categories, not every OS dialog you may still see. Real browsers may show clipboard permission prompts or deny readText until you click; explain that distinction in tickets separately from the none array. Pair with Browser Features for API presence rows and JavaScript Test when baseline scripting fails before clipboard code runs. Documentation portals adding one-click copy for code samples use this smoke after Firefox updates when readText behavior shifts. Permissions-Policy clipboard-read on parent frames blocks iframe copy while top-level smoke passes. VDI sessions with clipboard redirection disabled fail readText even when writeText succeeds, note virtualization layer in enterprise tickets. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. Safari write-allowed read-blocked patterns confuse “copy button broken” tickets, record which direction failed. DeviceHub typed permissions none coexist with browser clipboard prompts, explain both layers in enterprise notes. Staging http:// intranet pages cannot run modern clipboard, confirm users reproduced on HTTPS before escalating. Linux X11 clipboard managers versus Wayland compositors change readText behavior, note display server in desktop Linux tickets.

What this tool does

writeText when available, optionally readText where supported, and documents NotAllowedError, SecurityError, or missing API fallbacks. Messaging covers Safari/Firefox read limitations, enterprise policies, and the difference between execCommand fallbacks and modern Async Clipboard. Nothing copies your personal clipboard history to DeviceHub servers. Write success does not guarantee read success, engines treat read and write permissions differently. Electron webviews may wrap clipboard APIs differently, retest inside embedded shells when desktop Chrome passes. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. Permissions-Policy clipboard-read on embedders blocks iframe copy while top-level DeviceHub smoke passes. Non-HTTPS origins block modern clipboard, confirm secure context when staging reproduces on http:// intranet. ClipboardItem multi-MIME writes are out of scope for text smoke, image copy buttons need separate QA after text passes. Keyboard shortcut Ctrl+C in editable fields bypasses navigator.clipboard, production copy buttons using API still need gesture smoke here.

When to use it

Use Clipboard Test when in-app copy buttons fail, after enterprise clipboard policies change, when teaching secure-context requirements, or when users report paste works in native apps but not the browser. clipboard is undefined entirely. Run after deploying RDP or VDI environments where clipboard redirection interacts oddly with browser APIs. Image clipboard APIs are separate from text smoke, text success does not certify image/png write paths. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. Documentation sites with “copy code” buttons retest here after Firefox ESR upgrades because readText policies shift between releases. Electron webviews wrap clipboard unlike system Chrome, retest inside shell when desktop passes. Image clipboard APIs differ from text smoke, text success does not certify image/png write paths. Technical writers shipping Docusaurus or GitBook sites with keyboard-free copy buttons should run this smoke on Safari iPad after each major iOS release because readText policies shift independently from writeText success that QA verified on macOS. Custom paste event handlers in rich text editors intercept clipboard reads, retest on plain textarea pages first. Mobile share sheets are not clipboard API, text copy buttons on iOS may use different code paths than desktop writeText.

How it works

The Async Clipboard API requires secure contexts and user gestures for many operations; read access is especially restricted compared with write. query for clipboard-read may exist on some engines yet still prompt at call time. DeviceHub typed permissions remain none, none means no microphone-style grant is pre-recorded in DeviceHub schema, not that the browser stays silent. execCommand copy legacy paths may appear as fallbacks on older codepaths but are not universal and may be deprecated. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. Safari may allow write while blocking read, record which direction failed when both buttons exist on the production site you are debugging. VDI clipboard redirection disabled yields readText failures even when writeText succeeds, note virtualization layer. Documentation copy-code buttons retest here after Firefox ESR upgrades shift read policies. Firefox clipboard-read permission in about:config overrides defaults, power users may diverge from stock enterprise builds. Plain-text smoke ignores HTML clipboard MIME types used by rich email composers, marketing paste bugs may need format-specific QA.

Step-by-step instructions

1. Open Clipboard Test over HTTPS because clipboard APIs require secure context on modern browsers. Click copy control yourself, do not ask remote users to run automated copy on load without gestures.
2. Click the provided control to satisfy user-gesture requirements before any write attempt, automatic copy on load should fail by design. Try read only after successful write to separate direction-specific failures in tickets.
3. Run copy smoke and note whether the browser shows a clipboard permission prompt; record that in tickets even though DeviceHub typed permissions stay none. Note Safari/iOS version when readText fails while write succeeds, platform matrix shifts often.
4. Attempt paste read if offered and document NotAllowedError as browser policy rather than DeviceHub failure. If iframe copy fails, rerun top-level DeviceHub smoke to isolate Permissions-Policy on embedder.
5. Compare Browser Features for clipboard API presence when operations fail on Safari versus Chromium. Document VDI or RDP environment when clipboard redirection settings may interfere.
6. Distinguish in tickets between write failures (often gesture-related) and read failures (often permission-policy-related), support fixes differ. Revoke site clipboard permission after test on shared machines if org policy requires.

Common problems

Expecting clipboard write on page load without a click fails by design. Equating typed permissions none with no browser UI ever misleads support notes. Read failures on Firefox/Safari are often expected. Non-HTTPS origins block modern clipboard paths. Remote desktop can interfere with clipboard integration outside this page scope. execCommand fallbacks silently failing when disabled by CSP script-src breaks older copy snippets still shipped in production. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. Windows clipboard history tools interact oddly with readText, test with history disabled when results look inconsistent. Windows clipboard history tools interact oddly with readText, retry with history disabled when results inconsistent. execCommand fallbacks may be disabled by CSP script policies, failures can be policy not missing API. Safari Technology Preview clipboard changes land before stable, retest STP when copy regressions hit beta users only.

Privacy explanation

Test strings are benign placeholders. DeviceHub does not upload clipboard contents during the check. You control what you paste into tickets afterward. No microphone or camera permission is requested on this page. Successful readText briefly accesses clipboard contents you already control, avoid running read tests on shared machines while sensitive data is copied. Safari 17+ clipboard changes ship in release notes, retest after iOS/macOS updates when copy buttons regress. User gesture requirements mean automatic copy on load should fail, click controls during smoke, not page load. Remote desktop can break clipboard integration outside browser, local smoke still valuable before blaming RDP. Clipboard read probes touch whatever string is currently on the system clipboard, run write-only smoke on shared kiosks when HR spreadsheets might sit one paste away from accidental exposure. navigator.clipboard.write with ClipboardItem requires permission distinct from writeText, rich copy buttons may fail while plain text passes.