Clipboard copy actions fail when Plannotator runs in insecure browser contexts

[quanweiZhou]

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

[backnotprop]

Thanks for the clear report, and for including the console trace. Confirmed.

navigator.clipboard only exists in secure contexts (HTTPS or localhost), so in remote mode over plain HTTP it is undefined and every direct navigator.clipboard.writeText(...) call throws exactly the Cannot read properties of undefined (reading 'writeText') you saw.

We already ship a fallback-aware copy helper (packages/ui/utils/clipboard.ts) that goes through a copy-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 copyTextToClipboard helper (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]

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.