aboutsummaryrefslogtreecommitdiff
path: root/scripts/testing/archsetup-test.conf
diff options
context:
space:
mode:
authorCraig Jennings <c@cjennings.net>2026-07-16 13:40:26 -0500
committerCraig Jennings <c@cjennings.net>2026-07-16 13:40:26 -0500
commitace9fdd7a1a3d6581c407633d22d342c3a16f035 (patch)
tree1fdf8c47bef2490887f610ac9a6ba96742d73b98 /scripts/testing/archsetup-test.conf
parente3379e5f8adc54c6c32ba0164a97079d532ee1ec (diff)
downloadarchsetup-ace9fdd7a1a3d6581c407633d22d342c3a16f035.tar.gz
archsetup-ace9fdd7a1a3d6581c407633d22d342c3a16f035.zip
fix(gallery): hand the export over selected instead of faking a copy
The button said "copied" and nothing reached the clipboard. From a file:// origin Chrome refuses both programmatic paths: navigator.clipboard.writeText rejects NotAllowedError, and execCommand('copy') returns true while writing nothing. The truthy return is what let the page claim a success it never had. A hand-typed Ctrl+C works, so nothing about the clipboard is broken. I checked the rest of the chain: a Wayland-set clipboard crosses to X11, and Emacs reads it back correctly against a sentinel. So the page's only job is to hand the text over selected, and the reader's own copy does the rest. The comment I shipped earlier had this backwards, claiming Chrome couldn't write the clipboard at all. It's replaced.
Diffstat (limited to 'scripts/testing/archsetup-test.conf')
0 files changed, 0 insertions, 0 deletions