Repository navigation
Clipboard copy actions fail when Plannotator runs in insecure browser contexts #1173
Description
What happened?
Problem
Several Plannotator UI copy actions call navigator.clipboard.writeText(...) directly. This breaks when the app is opened in an insecure browser context, such as a non-localhost HTTP URL, remote/devcontainer session, or an environment where the Clipboard API is unavailable or rejects writes.
In those cases, copy buttons either silently fail or show a generic failure even though the browser could still support the legacy document.execCommand('copy') path.
The error message in brower console:
(index):4521 Failed to copy: TypeError: Cannot read properties of undefined (reading 'writeText')
at Ce ((index):4521:1930)
at $T ((index):61:128930)
at (index):61:134261
at On ((index):61:15163)
at Xk ((index):61:130183)
at u0 ((index):62:28961)
at pee ((index):62:28782)
Expected behavior
Copy buttons should work consistently in supported browsers, including when navigator.clipboard.writeText is unavailable or rejects due to browser security restrictions.
If all copy strategies fail, the UI should report the failure without crashing.
Plannotator version
plannotator 0.25.1
OS
Linux
Agent
Other
Where did it happen?
Annotate
Activity
backnotprop commentedon Aug 1, 2026
Thanks for the clear report, and for including the console trace. Confirmed.
navigator.clipboardonly exists in secure contexts (HTTPS or localhost), so in remote mode over plain HTTP it isundefinedand every directnavigator.clipboard.writeText(...)call throws exactly theCannot read properties of undefined (reading 'writeText')you saw.We already ship a fallback-aware copy helper (
packages/ui/utils/clipboard.ts) that goes through acopy-event /document.execCommand('copy')path when the async Clipboard API is unavailable or rejects, but most copy buttons predate it and call the API directly. There are roughly 27 such call sites across the plan editor, the review editor, and the shared components, which is why this shows up in so many places.Fix in progress: a shared
copyTextToClipboardhelper (Clipboard API first, legacy fallback second, and a clean failure signal so buttons can report "copy failed" instead of crashing), with every copy action routed through it. Will link the PR here.backnotprop commentedon Aug 1, 2026
Fix is up in #1174. It routes all 27 copy actions through a shared helper that falls back to the legacy copy path when the Clipboard API is unavailable or rejects, and copy buttons now report failure instead of crashing.
fix(ui): fall back to legacy copy in insecure browser contexts (#1174)