fix: copy resource names over HTTP - #1465
Conversation
The Wails clipboard shim replaced document.execCommand globally and routed every copy/cut through navigator.clipboard.writeText, returning true without observing the result. On insecure origins — where navigator.clipboard does not exist — that defeated the hidden-textarea fallback copyText relies on and fabricated a success result. Only Monaco's virtual selection needs the hijack; everything else now delegates to the native command and reports its real return value. Extracted the shim from main.tsx into an installable module so the delegation matrix is unit-testable, including copyText running against the patched document.
textarea.select() moves focus to the hidden aria-hidden element and remove() then drops focus to body. Return it to the previously focused element, but only when the textarea still owns focus (a copy handler may have focused something else), only when that element is still connected, and without scrolling it into view.
|
Thanks @CBOSSX - While verifying over a real plain-HTTP origin I hit a collision with the desktop entrypoint: Verified end-to-end on I'll migrate the ~30 other |
Description
Resource-name copy buttons now keep the modern Clipboard API as the primary path and fall back to a hidden textarea copy command when that API is unavailable or denied. This makes the reported button work when Radar is served from a plain-HTTP hostname or IP address, and the success icon only appears after a copy path succeeds.
Type of change
How has this been tested?
npm test --workspace @skyhook-io/k8s-ui -- src/utils/clipboard.test.ts(3 passed)npm test --workspace @skyhook-io/k8s-ui(146 files; 2549 passed, 1 skipped)npm run tsc --workspace @skyhook-io/radar-appnpm run lint --workspace @skyhook-io/radar-app(0 errors)make lintmake buildThe regression covers an unavailable Clipboard API, a rejected Clipboard API, and the successful modern path. The standalone
k8s-uiTypeScript command still reports the same nine test-only diagnostics on the exact upstream base SHA and on this patch; the production Radar Web type check and full build pass.Checklist
Related issues
Fixes #1269
Regression evidence
npm test --workspace @skyhook-io/k8s-ui -- src/utils/clipboard.test.tsexited1with the test present and production files unchanged from7ffa6e2959371818a1aa45123efa1b8b68ff419a.0with all 3 cases passing.Scope
Note
Medium Risk
Touches a global document.execCommand monkey-patch used by the desktop WebView and Monaco copy/cut. Behavior is covered by unit tests but remains environment-sensitive.
Overview
Resource-name copy now works when Radar is served over plain HTTP (no Clipboard API).
copyTexttriesnavigator.clipboard.writeTextfirst, then a hidden-textareaexecCommand('copy')fallback, and the checkmark only shows if a path actually succeeds.The Wails clipboard shim is extracted to
wails-clipboard.ts. ItsexecCommandpatch now hijacks copy/cut only when Monaco has a virtual selection; other callers (includingcopyText) go through the native command and get its real return value instead of a fabricated success.Reviewed by Cursor Bugbot for commit d460d13. Bugbot is set up for automated code reviews on this repo. Configure here.