Build Log
“Copied” Did Not Mean Copied
The share button reported success unconditionally. Nothing dramatic crashed; the interface simply told a lie. That made the bug a trust problem as much as a JavaScript problem.
The swallowed failure
The original helper attempted a clipboard write, caught any error, and still showed a success toast. The share-link handler then wrote “Link copied” without awaiting the operation. Browser permissions, insecure contexts, or clipboard API failures could therefore produce a confident false positive.
Other copy actions used the same helper but did not show the extra status line, which made the shared weakness less obvious. The visible symptom belonged to one button; the cause belonged to a reusable function.
Make success a value
The replacement helper returns a boolean. It awaits navigator.clipboard.writeText, falls back to a temporary read-only textarea and execCommand, and respects the fallback’s return value. Only a confirmed path produces success feedback.
If both methods fail, the interface exposes the raw share URL for manual copying. Tests forced API success, total failure, and legacy fallback. This matters because a test that exercises only the happy path cannot verify honesty.
What became standard
User feedback is an assertion about system state. Async operations must return an outcome, callers must await it, and failure should leave the user with a workable alternative. Silence is better than false certainty; an explicit fallback is better than either.
Try the current behaviour from the calculator, read the method, or review the site’s correction approach in Editorial Standards.