Which $destroy event should a directive with scope: false listen on for reliable listener cleanup?

Direct Answer

Register the cleanup handler on $element, not on scope. With scope: false there is no directive-owned scope—the link function receives the parent scope directly—so scope.$on('$destroy') attaches to a shared parent that may outlive or predate the directive's element removal. The version-agnostic pattern is to capture the deregistration function returned by scope.$on() and invoke it from $element.on('$destroy', cleanup), guarded by a flag so it runs exactly once.

Why scope.$on('$destroy') Is Unreliable Here

• No private scope exists. scope: false means the directive uses its parent scope. The $destroy event on that scope fires when the parent scope is destroyed (e.g., controller teardown, route change), not when this directive's element leaves the DOM.
• Timing varies across 1.4–1.8. In some versions the parent scope destroys before link cleanup runs; in others after. Neither ordering is guaranteed by the framework for scope: false directives.
• False positives. Sibling directives or parent controller destruction can trigger the parent scope's $destroy while this directive's element remains in the DOM, causing premature cleanup.

Version-Agnostic Cleanup Pattern

app.directive('myDirective', function () {
  return {
    scope: false,
    link: function (scope, $element, attrs) {
      var deregister = scope.$on('someEvent', handler);
      var cleanedUp = false;

      function cleanup() {
        if (cleanedUp) return;
        cleanedUp = true;
        deregister(); // exactly once
      }

      // Primary path: element removal triggers $destroy on the element
      $element.on('$destroy', cleanup);

      // Fallback: if parent scope destroys first, still clean up
      var parentDereg = scope.$on('$destroy', cleanup);
      // Optional: drop parent listener after element cleanup to avoid retention
      $element.on('$destroy', function () {
        parentDereg();
      });
    }
  };
});

How It Works

1. scope.$on('someEvent', handler) returns a deregistration function—capture it.
2. $element.on('$destroy', cleanup) fires when AngularJS removes the element (via ng-if, ng-repeat, $compile teardown, etc.). This is the per-element signal you need.
3. The cleanedUp flag guarantees the deregistration runs exactly once even if both the element and parent scope fire $destroy.
4. The optional parentDereg cleanup prevents retaining a closure reference to the destroyed parent scope.

One Diagnostic Detail That Changes the Recommendation

Does your DOM removal path actually trigger $destroy on the element? AngularJS only fires $destroy on an element when its scope is destroyed or when jqLite's remove()/empty() is used. If you detach elements via raw DOM APIs (element[0].remove(), jQuery .detach()) or a third-party library bypasses Angular's teardown, $element.on('$destroy') will never fire. In that case you must call cleanup() manually from your removal code.