ExpectedConditions on Angular 2+ apps: Is Protractor’s sync reliable?

Short answer

When you use ExpectedConditions on an Angular 2+ page, the condition only verifies the current state of the DOM element. It does not wait for Angular’s rendering or lifecycle hooks to finish. Protractor’s built‑in waitForAngular is designed for AngularJS and will time‑out on Angular 2+ unless you disable it. A dedicated Angular 2+ sync path is not part of current Protractor releases; manual waits with ExpectedConditions are the reliable approach.

Why this matters

• Framework sync vs. DOM state: waitForAngular relies on AngularJS digest hooks that Angular 2+ does not expose. Therefore browser.waitForAngularEnabled(true) often causes hangs or failures on modern apps.
• EC behaviour: EC repeatedly polls the browser. If an element has been inserted into the DOM but the component is still initializing, EC may resolve immediately, leading to flakiness.
• No built‑in Angular 2+ path: Protractor has not added a separate stability hook for Ivy. Until such a feature is released, developers must manage waits themselves.

Best practice for mixed test suites

1. Turn off automatic sync only for the tests that hit Angular 2+ pages:

   beforeEach(() => {
     browser.waitForAngularEnabled(false);
   });
   

2. After the Angular 2+ test block, restore sync if the rest of the suite uses AngularJS:

   afterEach(() => {
     browser.waitForAngularEnabled(true);
   });
   

3. Prefer EC.elementToBeClickable or EC.visibilityOf for interactions, but be aware that these only guarantee the element’s current visibility, not that the component’s logic is complete.

Diagnostic question

Do your Angular 2+ pages use a custom zone.js patch or an external library that attempts to expose a stability signal to Protractor? If so, the recommendation may change.