fix(angular): allow back button subscriptions to be tied to a DestroyRef - #31348

Issue number: resolves #

What is the current behavior?

BackButtonEmitter.subscribeWithPriority gives you no way to stop listening.

Platform is providedIn: 'root', so backButton is a single application-lifetime Subject. A component that registers a handler:

this.platform.backButton.subscribeWithPriority(10, (processNext) => {
  this.closeMyThing();
  processNext();
});

keeps that handler registered after it is destroyed. The callback keeps running — against a destroyed component — for as long as the app is alive, and every navigation to that page adds another one. The only way out today is to hold the Subscription and unsubscribe by hand in ngOnDestroy, which is easy to forget and impossible to notice going wrong: nothing errors, the handler just quietly still runs.

What is the new behavior?

• subscribeWithPriority takes an optional third argument, a DestroyRef. When it is passed, the stream is piped through takeUntilDestroyed, so the subscription ends with the component that opened it:

  this.platform.backButton.subscribeWithPriority(10, (processNext) => { ... }, inject(DestroyRef));

• Omit it and behaviour is byte-for-byte what it is today, so nothing existing changes.

• takeUntilDestroyed is handed an explicit DestroyRef rather than relying on an injection context — that is what makes it usable from the assignment inside the zone.run callback, which is not one.

Does this introduce a breaking change?

• Yes
• No

The parameter is optional and the no-argument path is unchanged. takeUntilDestroyed needs Angular 16, and this package already declares @angular/core: >=16.0.0, so it is within the supported range. It is the first use of @angular/core/rxjs-interop in the repository.

Other information

On testing. packages/angular's test script is echo 'angular no tests yet' and there are no unit specs in the package, so there is nothing here to extend — test/ holds e2e apps. I did not add a unit-test harness to the package, since introducing one is a much larger change than this fix and not mine to decide. What I did instead:

• Type-checked the change under --strict against real @angular/core and rxjs typings, including the this.pipe(...) : this union that subscribe is called on.
• The equivalent change has been running in production in an Ionic 8 app of ours, applied to the built fesm2022 output with patch-package, which is what prompted submitting it properly.

Happy to shape it differently — an overload instead of an optional parameter, or a separate method — if either fits the API better.