|
success
Two real bugs in the docs site copy-to-clipboard handler, both flagged by
copilot review on PR #1886 (deferred there because that PR is scoped to typos).
Bug 1: Copy label leaked into copied snippets on narrow screens
The handler read `currentTarget.offsetParent.innerText`. The same handler
appends a visible `.copyDiv` (with a 'Copy' <p>) into that container.
Below the 992px breakpoint the label is visible (see code-snippets.css
.copyDiv > p) so users got 'Copy' appended to every copied snippet.
Fix: extract text from the <pre> element inside the container instead,
which excludes the injected button. Also switched the lookup root from
`offsetParent` to `parentElement` so the source-of-truth is the DOM
relationship (the .copyDiv is inserted as a beforeend child of the inner
.highlight div via insertAdjacentHTML), not CSS positioning.
Bug 2: Failed clipboard writes still showed 'Copied!'
The try/catch only logged on failure but the surrounding code still flipped
the button into the copiedNotifier success state. Users got false success
when writeText rejected (insecure context, permission denied, etc.).
Fix: move the success UI flip inside the try, add an explicit failure UI
flip ('Failed' text + new `.copyFailedNotifier` class with red background)
in the catch. setTimeout still reverts both classes after 2s.
Verified in browser with a sphinx-rendered fixture (jQuery 3.7 + Pygments
output): both snippets copy their own text without the Copy label, success
flow shows Copied!, simulated writeText rejection shows Failed, both states
revert after 2s.
🤖 Generated by [robots](https://vyos.io)
|
