The button did nothing. No console error, no failed request, no red toast. I clicked it, and the page went on being a page.
I had spent the afternoon inside runInject(): the function that pulls a context block from the local gateway and drops it into whatever composer the host site is using. Edit, reload the extension, reload the tab, click. Nothing. On the third round I put a console.log on the first line of runInject. It never fired.
The button I was clicking was not wired to runInject. It was cbtn, the retired "🧠 My context" control from the previous design, and it called requestContext: the old in-page picker overlay. It had been superseded weeks earlier. It was still mounting on every page load, still painted with the same mark as its replacement, and still perfectly happy to handle a click.
Two entry points, one scope, no error
The shape that made it invisible:
// content.js — one IIFE, two mount paths
function mountContextButton() {
if (window.__vodouContextButtonMounted === MOUNT_TOKEN) return;
window.__vodouContextButtonMounted = MOUNT_TOKEN;
function runInject(site, forceComposer, composer, onDone, manual, ctl) { /* current */ }
function mountFab() { // the NEW control
if (document.getElementById('vodou-fab-wrap')) return;
// ...
run(report) { runInject(site, true, findComposer(), undefined, true); }
}
mountFab();
}
// ...elsewhere in the same IIFE, outside that closure:
mountCbtn(); // the OLD control — cannot see runInject, calls requestContext
runInject lives inside mountContextButton()'s scope. Nothing outside that closure can call it. So the retired control could not have been calling the current path even if I'd rewired it, and that's the part that took me embarrassingly long: the scope was the proof, sitting right there, and I read it three times as a detail instead of as an answer.
The mount guards made it worse by working. Ours are versioned on purpose: MOUNT_TOKEN is the manifest version, so reloading the extension re-arms the guard in already-open tabs instead of hitting a === true and returning early. The new control's guard is keyed on its own id. The old control had its own guard, keyed on its own id. Both cleared. Both mounted. Neither knew the other existed.
The standard advice is about orphaning. This wasn't orphaning.
Every result you get searching for this is about context invalidation. The classic Stack Overflow thread on orphaned content scripts and samber/cc-skills' content-scripts reference both cover it well: after an update the old script keeps running, loses chrome.runtime, every message throws, so you guard with isExtensionAlive() and show a refresh banner. AuditBuffet's pattern names the visible symptom exactly right: "ghost UI that does nothing when clicked."
None of it covers my case. My extension context was fine. chrome.runtime.id was there. isExtensionAlive() returned true, messaging worked, and the ghost button was shipping in the current bundle. There is no invalidation event to hang cleanup off when the thing that retired your code path was a refactor.
The class: a retired entry point that still boots
This is not a Chrome bug. It's what happens whenever a new implementation is added beside an old one in overlapping scopes and the old mount is left in the boot sequence: React components whose replacement ships but whose old addEventListener still runs from a stale useEffect, embedded JS SDKs (Stripe/Intercom-shaped) where v1's mount call survives in the host's snippet next to v2's, any server-rendered page that emits two <script> tags for the same widget.
Retiring a code path means deleting its mount call, not deleting its callers: an entry point that still executes at boot is live code, and if its handler is in a different scope from your current implementation, it is by construction calling something else.
Here's the check, in your own console, on your own page. Chrome DevTools only, since getEventListeners is a console builtin:
for (const el of document.querySelectorAll('[id*="myprefix"], [class*="myprefix"]')) {
console.log(el.id || el.className, getEventListeners(el));
}
Passing looks like one node per control, one click entry each. Failing looks like two nodes you only rendered once, or one node with two click listeners. Then expand the listener, click the source link, and read which file and line it lands on. If that line is inside code you believed you deleted, you just found it. Sixty seconds.
The backtick that eats the stylesheet
Second half of the same day, same file. The injected <style> is a 103-line template literal, content.js:1325-1428, with ten prose comments inside it explaining why each rule exists. 327 lines earlier there's a JS comment that reads // `manual` = a user-initiated trigger. Same writing habit, different container. A backtick inside that CSS comment terminates the template early, everything after it parses as JavaScript, and the file fails to parse, so nothing mounts at all, on all 22 hosts. You get Uncaught SyntaxError: Unexpected identifier pointing at a line nowhere near the backtick you typed.
The check is a shell loop, and it works on any repo that emits markup from template strings:
for f in $(git ls-files '*.js' '*.mjs'); do node --check "$f" || echo "BROKEN: $f"; done
Passing output is silence. Failing output is a filename and a line number that will not be where the mistake is: that's the tell, and it's why this takes an hour by eye and four seconds by parser.
Two rules out of one day. Grep your boot sequence for mount calls before you grep for handlers. And whatever delimiter your template literal uses, it is banned inside that literal, including in the comments, especially in the comments, because comments are where prose goes and prose is where backticks live.
Source: Your retired button is still mounted, still handling clicks by Chad Priest, from Building Vodou in Public.
