Skip to content

Logs and diagnostics: confirm a copy with the kit clipboard #82

Closed

Description

@elementalvoid

What to build

The copy actions — copying the visible log tail, the debug bundle directory, and the last archive's path — confirm that the copy happened, in the same way across all three.

Today a click writes to the clipboard and the screen does not change, so a user has no way to tell the click registered short of pasting.

Acceptance criteria

  • Each copy action confirms visibly without opening a new surface and without adding a control that must be dismissed.
  • The confirmation is reachable by assistive technology, and a repeated copy re-confirms rather than staying silent.
  • The copied text is byte-for-byte what the clipboard receives today, including the log tail's blank-line handling.
  • A copy that cannot be performed (empty tail, no archive yet) is still disabled or still produces the same refusal as now.

Notes

Small ticket. If the shared notice component from the notice ticket gives a better confirmation for one of the three, use it and say which.

Scope correction (found during implementation)

The app has two clipboard copy actions, not three. At 78e7a56 the only app clipboard writes are the logs tail (logs_view::copy_all) and the diagnostics bundle path (diagnostics_view::copy_bundle_path). There is no debug-bundle-directory copy control anywhere — the directory is only quoted in the Collect row's help text — and the only other Copy item is AppKit's editing selector for text selection, which the app cannot hook. Copying the folder is filed separately as #87.

So this ticket covers two actions, and its third bullet ("a copy that cannot be performed ... is still disabled or still produces the same refusal") applies to both.

Activity

  1. elementalvoid commented on Oct 31, 2026

    @elementalvoid
    OwnerAuthor

    Landed in main at 35691b2, merged from integration/kit-surface (CI green at 43223e2). Gate on the merged tree: cargo fmt --all -- --check, cargo clippy --workspace --all-targets -D warnings, cargo test --workspace — all clean.

    What the reviews changed — and the biggest finding in the whole stack. The first attempt mapped a successful copy to Role::Alert and re-announced by minting a new node per press. That announces nothing: gpui-pre 0.3.10 sets no live region, and every accesskit adapter gates announcements on live != Off. So nothing this app had ever rendered was announced on any platform. This ticket's review found that and fixed it centrally — every non-quiet Notice and EmptyState is now a polite live region, mutating the element's own node in place rather than adding one, so the announce-once property #76 established still holds. Severity::Success maps to Role::Status; the confirmation keeps a stable id with the press count in both name and value (the adapters diff different fields); a stale confirmation clears when the payload changes; and the diagnostics row reserves its slot so the button cannot slide out from under the pointer.

    Scope correction. Two copy actions exist, not the three this ticket assumed. The missing folder copy was filed as #87 and has since landed as #90, reshaped into a reveal in the file manager rather than a second clipboard write.

    Still manual. Real screen readers on all three platforms. The platform truth is documented in the module docs: Windows announces mount and name changes, AT-SPI announces a name change on a node that stays, and macOS announces only a changed value.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or requestready-for-agentFully specified, ready for an AFK agent

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions