Clipboard copy actions fail on plain-HTTP LAN origins

[Willhong]

Description

Copy actions backed by the shared clipboard helper fail when bb is opened from another device over a plain-HTTP LAN URL, such as http://<host>:38886. Clicking a copy affordance shows Failed to copy and leaves the clipboard unchanged.

Reproduction

1. Run bb so the frontend is reachable from the local network.
2. Open it from another device using a non-loopback HTTP origin.
3. Click any copy action backed by the shared clipboard helper, such as a path or message copy button.

Expected behavior

The selected text is copied to the system clipboard.

Actual behavior

The copy fails and bb displays Failed to copy.

Root cause

Browsers restrict navigator.clipboard.writeText() to secure contexts. A plain-HTTP LAN origin is not considered secure, so the Clipboard API may be unavailable or reject the request. The shared helper currently treats that as a terminal failure even though bb supports this access pattern.

Impact

Because copy affordances share the helper, this affects multiple copy actions throughout the app rather than one specific component.

Proposed fix

Retain the modern Clipboard API on secure origins and fall back to a temporary textarea plus the browser editing copy command when the API is unavailable or rejects. Restore focus and selection after the attempt.

Draft implementation: #1589

AGENT GENERATED: by GPT-5.6 Sol

[SawyerHood]

Reproduction & root-cause report: https://get-bb.github.io/reports/issues/1590.html

• Verdict: REPRODUCED · root-cause confidence: high
• Root cause (short): apps/app/src/lib/clipboard.ts only uses navigator.clipboard.writeText, which browsers expose solely in secure contexts; on a plain-HTTP non-loopback origin navigator.clipboard is undefined so every helper-backed copy action toasts "Failed to copy" without trying the execCommand('copy') fallback.
• Linked PR review: Fix clipboard copy on insecure origins #1589 → MERGE — Fixes the root cause at the right layer (client-only textarea+execCommand fallback after the modern API); verified in a real insecure-origin Chromium session that the clipboard actually receives the text and that the present-but-rejecting API branch is rescued too. Non-blocking: plugins/connect and
• Proposed fix: Two-strategy helper as in PR Fix clipboard copy on insecure origins #1589: try navigator.clipboard.writeText when present; on absence or rejection synchronously copy via an off-screen textarea + document.execCommand('copy'), then restore focus/selection. Follow up by guarding the three direct navigator.clipboard.writeText calls in plugins/connect/app.tsx and plugins/github/app.tsx (or expose an experimental_ clipboard helper from the plugin SDK), and add a unit assertion that execCommand is invoked before the returned promise settles when the API is absent.
• Caveats: Live repro used headless Chromium 145 at a real non-loopback IP origin (via a local TCP forwarder because the dev app binds 127.0.0.1); Firefox/Safari and iOS over LAN were not exercised, though the secure-context gating is spec-mandated in all engines. Issue Type/Effort project fields were not readable with the available token scopes (Priority Medium taken from the task prompt). PR Fix clipboard copy on insecure origins #1589 was test…

The report has copy-paste repro steps, screenshots where the bug is visual, code permalinks at 16ceb3a54, and repro artifacts. It was independently re-run by a second agent (see its Verification section).

AGENT GENERATED: by Claude Opus 5