Skip to content

fix: confirm task copy only after clipboard success - #62

Open
ooiuuii wants to merge 1 commit into
tt-a1i:mainfrom
ooiuuii:fix/task-copy-success-feedback
Open

ooiuuii wants to merge 1 commit into
tt-a1i:mainfrom
ooiuuii:fix/task-copy-success-feedback

Conversation

@ooiuuii

@ooiuuii ooiuuii commented Oct 9, 2026

Copy link
Copy Markdown

Why

The Tasks Copy button immediately reports 'Copied task line' while its parent discards the clipboard Promise. Both desktop and mobile task surfaces can therefore report success for a pending write, a rejection, or an unavailable clipboard API.

Approach

Await a boolean result from the existing copyTextToClipboard helper (including its existing fallback) before displaying success. Clear prior feedback on a new click and use a per-row request counter to discard obsolete completion feedback and unmounted-row results. Preserve exact raw markdown selection and existing error logging. One existing owner file changes; no dependency or server changes.

Validation

New Chromium checks on 2026-10-09 against main f8f1343:

  • RED 02:22:07–02:22:10 UTC: six false-success assertions, pending/rejected/missing API on desktop and mobile
  • GREEN 02:22:34–02:22:45: both actual surface components cover pending, rejection, missing API, exact raw line, success, repeated actions, overlapping writes, latest success, 1.5-second feedback expiry and settlement after unmount/remount. 26 observations, no page errors
  • Failure/delayed-success cases inject navigator.clipboard and force the fallback to return false. Separate user-click controls call Chromium's real writeText, which fulfilled on both surfaces; OS clipboard readback/paste was NOT tested
  • pnpm install --frozen-lockfile, pnpm check, pnpm build, web-source TypeScript and git diff --check passed
  • One scoped review found no blockers; no subsequent source changes

Browser proof mounts real TaskGraphDrawer/MobileTasksSection and shared TaskGraphContent/TaskItem with fixture markdown over loopback HTTP. No backend mutation is involved. Mobile means the actual mobile component in a 390x844 Chromium viewport, not physical-device/WebKit proof. Initial external harness parsing/serialization faults were corrected before the valid untouched-main RED; no product changes preceded RED.

Runnable diagnostic retained outside the production diff under the current UI testing exception. Not run: full pnpm test, whole-project tsc, full-app navigation/production CSS, OS clipboard readback, real mobile/Windows/macOS, release/package/native matrix. Existing style/build warnings retained; no full-suite or remote-CI pass claimed.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant