aboutsummaryrefslogtreecommitdiff
path: root/tests/package-inventory/test_package_inventory.py
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
commit6f30e0d6d75a140c3d60966de698d67cd23afcd0 (patch)
tree1fdf8c47bef2490887f610ac9a6ba96742d73b98 /tests/package-inventory/test_package_inventory.py
parentb23d41767eee19d1cbb2aad0c72326a1a898a451 (diff)
downloadarchsetup-6f30e0d6d75a140c3d60966de698d67cd23afcd0.tar.gz
archsetup-6f30e0d6d75a140c3d60966de698d67cd23afcd0.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 'tests/package-inventory/test_package_inventory.py')
0 files changed, 0 insertions, 0 deletions