INT-3396: adjust tests to support both zoneless/zone.js change detection

[michalnieruchalski-tiugo]

Summary

No production code was changed in this PR. The only changes are to the test infrastructure and the README.

The test suite now runs against a zoneless Angular environment by default, matching the direction Angular is heading (zoneless by default since Angular 21). Tests that specifically verify zone.js-based behavior explicitly opt into provideZoneChangeDetection() on a per-test basis.

This ensures that the TinyMCE Angular component works correctly in both zoneless and zone.js-based applications.

What changed

• Default test environment switched to zoneless — InitTestEnvironment.ts now uses provideZonelessChangeDetection() instead of provideZoneChangeDetection().
• Zone.js-specific tests explicitly opt in — NgZoneTest and the zone.js context in EventBlacklistingTest provide provideZoneChangeDetection() at the test level.
• Event blacklisting test covers both modes — the test now runs in both a zoneless and a zone.js context, verifying event binding works correctly in each.
• README updated — replaced the "Not yet Zoneless" section with a "Zoneless Support" statement confirming the component works in both modes.

FAQ

Can I use this integration in a zoneless Angular application?

Yes. The TinyMCE Angular component works in zoneless applications without any additional configuration. No production code changes were needed to support zoneless — the component was already compatible.

Can I use this integration in a zone.js Angular application?

Yes. The component continues to work with zone.js-based change detection, just as it always has. The component injects NgZone and uses it to guard against zone pollution — ensuring that TinyMCE's internal activity doesn't trigger unnecessary change detection cycles. This has always been the case and is not new to this PR.

https://angular.dev/best-practices/zone-pollution

Are you sure we are zoneless? I can see NgZone injected in the editor component.

Yes. Injecting NgZone does not make the component zone-dependent. In a zoneless application, Angular provides a no-op NgZone instance — calls to NgZone.run and NgZone.runOutsideAngular simply execute the callback directly without any zone-related side effects. We keep these calls because they are still needed for applications that use zone.js, and as the Angular docs state that removing them could cause performance regressions for those users.

NgZone.run and NgZone.runOutsideAngular are compatible with Zoneless

NgZone.run and NgZone.runOutsideAngular do not need to be removed in order for code to be compatible with Zoneless applications. In fact, removing these calls can lead to performance regressions for libraries that are used in applications that still rely on ZoneJS.

https://angular.dev/guide/zoneless#requirements-for-zoneless-compatibility

Are you sure you're zoneless? I can see zone.js in our package.json and imported in the tests.

The zone.js dependency and import exist solely for testing purposes. Our test suite needs to verify that the component works correctly in both zoneless and zone.js-based applications. To test the zone.js path, we need zone.js loaded so that tests can opt into provideZoneChangeDetection(). Importing zone.js patches native browser APIs, but Angular does not use those patches for change detection unless explicitly configured to do so. The default test environment uses provideZonelessChangeDetection(), so the majority of tests run in a truly zoneless context. Once Angular drops zone.js support entirely, the import, the zone-specific tests, and the zone.js devDependency can all be removed.

If no production code changed, why did tests fail when you enabled zoneless change detection?

The tests themselves made assumptions that are only valid in a zone.js environment. Specifically, the event blacklisting test asserted that event callbacks run inside NgZone (NgZone.isInAngularZone() === true). In a zoneless application there is no Angular zone, so this assertion doesn't apply. The fix was to split the test into two contexts — one zoneless and one zone.js-based — and only assert zone membership in the zone.js context. Similarly, NgZoneTest explicitly verifies that events run inside Angular's zone — this is inherently a zone.js-specific concern, so it now opts into provideZoneChangeDetection() at the test level.

Is importing zone.js in tests a good idea? Won't it affect zoneless tests?

Yes, importing zone.js patches native browser APIs (addEventListener, setTimeout, etc.), so zoneless tests will run against patched APIs rather than native ones. In practice, this shouldn't matter — zone.js is a well-tested library, the patched APIs behave the same as the native ones, and it may affect performance slightly at most. The only way to avoid this would be to run two separate test runner instances — one with zone.js loaded and one without — which isn't worth the complexity.

Shouldn't we run all tests twice — once zoneless and once with zone.js?

I reviewed all the tests and where I judged it matters — such as event blacklisting — I run them in both modes. For the rest, I don't think running with or without zone.js makes a difference given the kind of tests we have, so I run them once in the default zoneless environment. This is a judgment call, and if we find cases where it does matter, we can always add a zone.js context to those tests later.