How does waitForAngularEnabled work?

Question

I am curious how does waitForAngularEnabled() work? Though it doesn't seem complicated, however, I couldn't get any satisfied answers anywhere. So hopefully someone helps me get cleared.

My goal is to check criteria and pause/lock running test until the criteria is meet. Here are cases for example.

A. to pause running test and wait until page gets loaded

    ...
    let theElement = ...;
    browser.waitForAngularEnabled(false);
    browser.wait(protractor.ExpectedConditions.presenceOf(theElement));

B. to use browser.wait(), the alternative way for similar purpose with A

    browser.wait(() => {
        browser.waitForAngularEnabled(false);
        return browser.isElementPresent(by.id('the-element-id'));
    }, timeout); // timeout may not be given

So the question is:

1. What will happen once waitForAngularEnabled(false) is invoked? (once the criteria is meet or timeout occur in my case)
2. Should I revert waitForAngularEnabled(true) to continue normal testing?
3. If I should do, where to put it?

Hope to get clear answers with some background principle.

Thanks!

Answer 1

1. What will happen once waitForAngularEnabled(false) is invoked? (once the criteria is meet or timeout occur in my case)

Empirically I have found that this seems to cause Protractor to behave as merely Webdriver. It does not wait for Angular to "settle down" (no pending HTTP requests or view updates), which is the behavior for true. Instead, if you use the false setting, you will need to use ExpectedConditions or similar approaches in order to verify preconditions to execute test steps reliably, just as you would with an ordinary Webdriver test.

2. Should I revert waitForAngularEnabled(true) to continue normal testing?

Yes. However, I have found that in Protractor 5.1.1 and 5.1.2, whether using control flow or not, scattering different waitForAngularEnabled values throughout your tests in the same execution seems to yield unpredictable results; that is, the enabled state does not follow the same asynchronous semantics of other Protractor/Webdriver calls. So far, my conclusion is that you cannot reliably mix waitForAngularEnabled(false) and waitForAngularEnabled(true) in the same execution. I suspect that this is a Protractor bug, but I have not yet developed a simple and reliable test to prove it in support of submitting a Protractor issue. There was a possibly related issue here, now closed but incompletely diagnosed.

3. If I should do, where to put it?

"Before" you make Protractor/Webdriver calls that require restoring the waiting-for-Angular semantics. However, as mentioned above, it's not clear that you can reliably guarantee that such calls will truly be made in the context of the true setting.

If you must have some tests that use false and others true, you could run them in separate executions (separate processes; don't run them with the same protractor or ng e2e command). I have encountered no problems when that approach is taken.