Failed: script timeout: result was not received in 11 seconds From: Task: Protractor.waitForAngular() - Locator: By(css selector, #my-btn) Failed: script timeout: result was not received in 11 seconds From: Task: Protractor.waitForAngular() - Locator: By(css selector, #my-btn) typescript typescript

Failed: script timeout: result was not received in 11 seconds From: Task: Protractor.waitForAngular() - Locator: By(css selector, #my-btn)


I had some trouble with this. There are a few things you can try.

  1. Manually check to see if you have any timed operations. My app, for example, had a timer that does a health check every 5 minutes. But this timer operation being on the stack constantly meant that Angular never stabilized.

If you do find such an operation, you can use ngZone.runOutsideAngular() to keep it from destabilizing your tests.

constructor(    private ngZone: NgZone  ) {}ngOnInit() {  this.ngZone.runOutsideAngular(() => {    this.appStatusInterval = interval(this.appStatusUpdateIntervalTime)       // rest of your code here    });  });}
  1. Open the dev tools and run getAllAngularTestabilities(). Try to get what information you can from there. You can try to get extra data from the source code. This bit in particular might be useful to you:
isStable(): boolean {    return this._isZoneStable && this._pendingCount === 0 && !this._ngZone.hasPendingMacrotasks;}

You can at least get more of an idea on what's destabilizing Angular by checking each of these three conditions in turn.


As the error message suggests, a simple solution is to use waitForAngularEnabled(false) in conjunction with hard-coded sleep for however long you want to allow your page to load without failing the test (say, 3 seconds). The test will only be flaky if the page isn't actually finished loading into a static state after 3 seconds:

await browser.sleep(3000)

and then run your expectations while waitForAngularEnabled is false

browser.waitForAngularEnabled(false)// expectations herebrowser.waitForAngularEnabled(true)

This isn't the preferred solution when you can use graceful callbacks to confirm that Angular is done and your element is loaded. If the page loads faster than 3 seconds, your test is wasting time... It is, however, simple, readable and reliable. It allows you to enforce a limit on the page loading time while also being able to check the element in an environment free from the unpredictability of Protractor's behavior in regard to angular callbacks on pages that aren't playing nice. Reliability is more important than performance when it comes to front-end automation.