Files
voculinux/tests
Jakob JensenandGitHub aae1f4b474 fix(clipboard): keep paste-injection copies out of clipboard history 🤖🤖🤖 (#956)
* fix(clipboard): keep paste-injection copies out of clipboard history

The clipboard-paste injection path writes the dictated text to the
clipboard only to feed the paste chord, then restores the previous
content (#588, #646). Clipboard managers such as Klipper and cliphist
still record that transient copy, so every dictation lands in history.

Mark the injection copy with `wl-copy --sensitive`, which clipboard
managers honour by skipping the entry. The flag is probed once via
`wl-copy --help` (added in wl-clipboard 2.2) so older builds keep
working. It is only set when Copy to Clipboard is off: with that
setting on, the dictated text is meant to stay, so it remains an
ordinary copy. Restoring the user's previous content is never marked
sensitive. xclip/xsel have no equivalent and are unchanged.

* test(clipboard): address review on sensitive paste copies

- Move the unittest main guard below TestSensitivePasteCopy so running
  the file directly also runs the new tests.
- Add -> None return hints to the new test methods.
- Cover _copy_to_clipboard forwarding the sensitive hint when a tool
  declines and the next one is tried.
- Docs: history suppression needs wl-copy 2.2+ and a clipboard manager
  that honours the hint; older wl-copy and the XWayland xclip/xsel path
  still produce ordinary copies.

* fix(clipboard): type the wl-copy probe cache and adapt the X11 paste test

- Declare _wl_copy_sensitive_supported as a typed class default instead
  of reading it through getattr(), which mypy (now in CI since #968)
  flags as returning Any.
- test_plain_x11_clipboard_paste_uses_xdotool_and_x11_clipboard
  asserted the exact _copy_to_clipboard kwargs. Check the text and the
  X11 tools instead, so it does not depend on the sensitive hint (which
  xclip ignores) or on the copy_to_clipboard setting.

* test(clipboard): wait for the restore thread instead of a fixed sleep

TestSensitivePasteCopy slept 0.5 s and hoped the background restore had
run. On a slow runner the patches could end first. Wait on an event set
by the restore copy, inside the patches, with a generous timeout.
2026-10-26 20:25:40 -07:00
..