The Copy Button That Broke Without Anyone Touching It

A copy button that had worked for years stopped doing anything in some browsers, with no error and no message, because a 2016 helper file had claimed a shared page-level name, Clipboard, and browsers later started using that same name for their own built-in copy feature. On the affected browsers, the helper’s setup step failed before it could attach a click job to the button, so the button sat there and did nothing. In my browser it still worked, and in another it didn’t, which made the problem hard to show to anyone. Nothing near the button had changed, and no release or error report pointed to it.

That was strange because nobody had changed that part of the site. There had been no recent release, no change near the copy button, and no report that pointed to an obvious problem. The code was the same code that had worked for years.

The first thing I tried was looking for the usual trail of crumbs. I checked whether anything had been released. I looked for a change near the button. I looked for an error report. That search got me nowhere. There was no helpful trail. It cost patience, because the button worked in some browsers and failed in others. A problem that disappears when you try to show it to someone can make you doubt your own eyes.

The reason turned out to be a global variable. That is a fancy name for a shared label on a web page, like a shelf in a kitchen that anybody using the kitchen can claim. Years ago, an old copy helper put its own thing on the shelf and called it Clipboard. The browser later put its own thing on that same shelf and used the same name.

For a long time, there was room for the old helper. Then browsers added their own way to handle copying. The browser’s Clipboard was real, but it was not the kind of thing the old page could turn into a new copy helper. On affected browsers, the page tried anyway, failed while setting itself up, and never connected the button to the copying job.

That is why the failure was so quiet. Nothing was wrong with the words being copied. Nothing was wrong with the button a person could see. The problem happened earlier, in the small bit of setup work that tells the button what to do when it is clicked. If that setup fails, the button has no job.

The obvious response was to update the old copy helper. Newer versions use a different name, so they avoid this exact clash. I did not treat that as the same day fix. The helper was used across many pages, and there was no easy automatic way to check every place it touched. Updating a file from 2016 could solve one broken button and quietly disturb other pages. That was too large a gamble for a problem that had one known spot.

Instead, the fix started at the button itself. Before trying to use the old helper, the page now checks whether a working copy helper is really there. It looks for the newer name first and the older name second. If neither one is usable, it does not let that failure stop the rest of the page.

Then it has two backup plans.

First, it asks the browser to copy the text directly. The same newer browser feature that caused the name clash can also do the copy job without the old helper. If that option is unavailable, the page uses an older trick: it makes a temporary text box, moves it far off the screen, puts the embed code inside, selects the text, copies it, and removes the box right away.

That temporary text box is not elegant, but it is easy to picture. It is like writing a phone number on a scrap of paper just long enough to move it from one place to another, then throwing the paper away. The important part is that the page cleans it up even if copying fails. Nothing gets left behind after a bad click.

The text itself also got a backup. The button carries a copy of the embed code, but the page can also read the text from a fallback spot on the screen if the first copy is empty. There are now backups for both parts of the job: how to copy, and what to copy.

The repair shipped the same day. It did not require rebuilding the whole page setup or changing every page that used the old file. It made one small place sturdier while leaving a bigger software update for a time when it could be checked carefully.

I think the useful lesson is not that every old tool is bad. It is that a small feature can depend on an agreement nobody wrote down. In this case, the agreement was that a common word like Clipboard would stay available forever. The browser eventually needed that word for itself. The old helper lost the argument, even though nobody had touched the button.

The button failed because a word, Clipboard, that the old helper had claimed years ago was taken over by the browser itself, and the helper’s setup step broke before it could attach a click job to anything. That is why the fix was two backups, one for how to copy and one for what to copy, rather than a new helper: the 2016 file was left alone, and the page now checks that a usable copy helper exists before it trusts one. The button itself never changed. Its failure came from a shared name the browser needed back, and no release, no error report, and no edit near the button could have shown that.

dxdev LESSON · paste into your AI coding agent
LESSON: A shared global name is a contract you never signed
SOURCE: dxdev.com/blog/2026-02-19_copy-button-that-broke-without-anyone-touching
WHAT HAPPENED: A copy-to-clipboard button stopped working in some browsers with no release, no error, and no visible change to the code. The cause was a naming collision: an old copy-helper library had claimed the global identifier Clipboard years earlier, and a later browser update introduced its own native Clipboard API under the same name, so on updated browsers the old helper's setup silently failed and the button's click handler never got wired up. The fix checked for a working copy mechanism before using it, preferring the native API, then a hidden-textarea fallback, and cleaned up the fallback element immediately after use.
THE RULE: A global variable or identifier name is an implicit contract with everything else that might claim it, including the browser platform itself, and that contract can be broken by a platform update you never shipped. A feature that depends on a shared name needs a feature-detection check, not blind trust that the name still means what it used to.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any code that defines or relies on a global identifier with a common or platform-reservable name (Clipboard, fetch, Promise) without a feature-detection check for whether the platform now owns that name.
  2. Any click handler or interactive control with a single point of failure in its setup step, with no verification that the feature it depends on is actually present before wiring up the click.
  3. Any copy, clipboard, or similar convenience feature with no fallback path if the primary mechanism is unavailable.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.