In the browser DOM, why does el.removeEventListener('click', () => save()) fail to remove a listener added with el.addEventListener('click', () => save()), and what exactly has to match for removal to succeed?

## The listener list and its key Every `EventTarget` keeps a list of registered listeners. Each entry records the event type, the callback, the capture flag, and the remaining option values. When you call `removeEventListener(type, callback, options)`, the browser looks for an entry whose **type**, **callback** and **capture** all match, and removes the first such entry. Nothing else is compared. That three-part key explains every surprising removal failure you will meet. ## Function identity, not function source ```js el.addEventListener('click', () => save()); el.removeEventListener('click', () => save()); // removes nothing ``` Each arrow-function expression evaluates to a brand-new function object. The two look identical in source, but they are different values, so the comparison fails and the listener remains. The browser has no way to compare "what the function does" — identity is the only thing it can check. The same applies to anything that manufactures a function at the call site: ```js el.addEventListener('click', this.onClick.bind(this)); el.removeEventListener('click', this.onClick.bind(this)); // a different bound function ``` `bind` returns a new exotic function object every time it is called. So does a factory such as `makeHandler(id)`. If you want to remove it, you have to hold on to the exact object you passed in: ```js this.boundClick = this.onClick.bind(this); el.addEventListener('click', this.boundClick); // later el.removeEventListener('click', this.boundClick); ``` ## Capture is part of the key A listener registered on the capture side is a *different registration* from one registered on the bubble side, even with the same type and callback — and you may legitimately have both. So removal must agree: ```js el.addEventListener('scroll', onScroll, { capture: true }); el.removeEventListener('scroll', onScroll); // no match el.removeEventListener('scroll', onScroll, true); // match el.removeEventListener('scroll', onScroll, { capture: true }); // also a match ``` The boolean third argument and `{ capture: … }` are interchangeable for this purpose; a missing third argument means `capture: false`. This is the second most common cause of a listener that "will not come off": the code that adds and the code that removes drifted apart on the flag. ## The other options are ignored on removal `once`, `passive` and `signal` take part in *registration* only. Passing `{ once: true }` or `{ passive: true }` to `removeEventListener` changes nothing about the match — the browser reads only `capture` from the options you hand it. You also do not need to pass the *same options object*; a fresh object with the same capture value matches fine. ## Duplicate registration is silently ignored The same key rule governs adding. If the (type, callback, capture) tuple is already in the list, `addEventListener` does nothing: ```js el.addEventListener('click', fn); el.addEventListener('click', fn); // discarded el.click(); // fn runs once ``` This is genuinely useful — an idempotent `attach()` is safe to call twice. But note the flip side: one `removeEventListener` call is then enough to detach it. It also means the duplicate-suppression only works for a *stable* callback reference; if `attach()` creates a new arrow function each time, every call really does add another listener, and you now have a leak you cannot clean up. ## The failure is silent `removeEventListener` returns `undefined` and never throws when nothing matches. There is no console warning, no return value to check. The only observable symptom is that the handler keeps firing — often long after the component that owned it was torn down, keeping its closure and any DOM nodes it captured alive. That is why this shows up in interviews as a memory-and-correctness probe rather than an API trivia question. ## Ways to stop worrying about identity Three patterns remove the problem instead of solving it repeatedly: - **Named references.** Declare the handler once, store it, remove that. The discipline is simple but easy to get wrong across a large component. - **`{ once: true }`.** For a genuinely one-shot listener, the browser removes it for you after the first invocation, so no reference is needed at all. - **`{ signal }`.** Register listeners with an `AbortSignal` and call `controller.abort()` at teardown. Removal no longer depends on holding each callback, which means anonymous inline handlers become safe to use. In code you own, the third pattern is usually the right default: one controller per lifecycle, one `abort()` in the teardown path, and the identity rule stops being something a reviewer has to check by eye.