Protractor's Page Objects and Automatic Waiting: Two Ideas Worth Keeping After the Framework Is Gone

Protractor is dead. The Angular team deprecated it, support ended around 2023, and it no longer receives security or browser-compatibility fixes. If you are starting a new test suite, use Playwright, Cypress, or WebdriverIO instead. But if you inherited an Angular app with a few hundred Protractor specs — or you are planning a migration — two of its core ideas are worth understanding properly, because they explain both why the suite behaves the way it does and what you should carry into whatever replaces it.

Those two ideas are automatic synchronization with Angular's digest cycle, and the page object pattern as the organizing principle for specs. This post covers how each actually works, where each one bites you, and a concrete example you can adapt.

How automatic synchronization actually works

Most E2E flakiness comes from a simple race: the test clicks a button before the app has finished rendering the thing it wants to click. Protractor's signature feature was that, before each action, it called browser.waitForAngular(), which asks the running Angular app whether it has settled — no pending $http requests, no outstanding $timeout tasks, no digest cycle in progress. Only then does the click or assertion proceed.

The practical consequence: well-behaved Protractor suites contain almost no browser.sleep() calls. If you see sleeps sprinkled through a legacy suite, that is usually a symptom of one of two things — the page under test is not actually Angular (a login page served by a different stack, a third-party widget in an iframe), or the app has work Protractor cannot see settling.

For the non-Angular case, the escape hatch is explicit:

// In your spec or onPrepare — run in the Node process
// that executes your Protractor tests.
await browser.waitForAngularEnabled(false);
await browser.get('https://example.com/sso-login');
// ... log in on the non-Angular page ...
await browser.waitForAngularEnabled(true);
await browser.get('/dashboard'); // Angular app resumes sync

On older Protractor versions you will see browser.ignoreSynchronization = true instead; it is the same switch under an older name. Which one exists depends on your installed version, so check before copying either form.

The failure mode nobody documents: the test that hangs forever

Automatic waiting has a silent failure mode. If your app uses recurring $interval timers or long-polling HTTP requests, Angular never reports itself as "settled," and waitForAngular() waits indefinitely until Jasmine's timeout kills the spec. The symptom is a test that passes locally and hangs in CI, or a suite that got mysteriously slower after someone added a live-notification poller.

The fix is not more sleeps. It is either moving the polling out of Angular's tracking (for example, running the interval outside $interval so it does not count as pending work), or disabling synchronization for the specific specs that hit that screen and using explicit waits on a known element instead. When you migrate away from Protractor, note that Playwright and Cypress solve this differently — they wait on DOM state and network idleness heuristics rather than asking the framework — so a screen that hangs Protractor may "just work" in the new tool, which can mask a real performance problem in the app.

The page object pattern: the decision that outlives the framework

The second idea is not Protractor-specific at all, which is exactly why it matters. A page object is a class that owns the locators and interactions for one page or component, so specs read as intent ("log in as an admin, expect the dashboard greeting") instead of selector soup. When a template changes, you fix one file instead of forty specs.

// login.page.ts
import { browser, by, element, ElementFinder } from 'protractor';

export class LoginPage {
  // Prefer stable test hooks over Angular-internal locators.
  private username = element(by.css('[data-testid="username"]'));
  private password = element(by.css('[data-testid="password"]'));
  private submit = element(by.css('[data-testid="login-submit"]'));

  async navigate(): Promise<void> {
    await browser.get('/login');
  }

  async loginAs(user: string, pass: string): Promise<void> {
    await this.username.sendKeys(user);
    await this.password.sendKeys(pass);
    await this.submit.click();
  }
}

// login.spec.ts
import { LoginPage } from './login.page';

describe('login', () => {
  it('shows the dashboard after valid credentials', async () => {
    const page = new LoginPage();
    await page.navigate();
    await page.loginAs('[contact removed]', 'correct-horse');
    expect(await browser.getCurrentUrl()).toContain('/dashboard');
  });
});

Run this with npx protractor protractor.conf.js from the project root, using whatever credentials your test environment seeds — do not point it at production. Note the async/await: old Protractor relied on the WebDriver promise manager to make calls look synchronous, but that was removed (SELENIUM_PROMISE_MANAGER: false became the default). If you are resurrecting an old suite and every test fails with confusing promise errors, that version change is the likely cause — check your installed protractor and selenium-webdriver versions before rewriting anything.

The trade-off: Angular-specific locators

Protractor shipped locators tied to Angular internals — by.model, by.binding, by.repeater, by.cssContainingText. They are convenient, but they couple your tests to framework implementation details. A template refactor that swaps ng-model for a reactive form control breaks by.model locators even though the page looks identical to a user. And none of these locators exist in Playwright or Cypress, so every one of them is migration debt.

The deliberate engineering decision, even inside a legacy Protractor suite, is to add data-testid attributes to templates and locate on those. The example above does this. It costs a small amount of markup, survives framework migrations on both the app side and the test side, and makes the page objects the single place that knows how anything is found.

What to actually do with this

If you maintain a Protractor suite today: stop adding Angular-internal locators, route new selectors through data-testid, and keep page objects strict — they are the layer that will port cleanly. If you are migrating, your page objects map almost one-to-one onto Playwright's page object style, and the specs themselves often need only mechanical translation. Either way, verify the end-of-life status against the Protractor repository's deprecation notice and your own package.json before quoting dates in a migration plan, and treat any spec that needs waitForAngularEnabled(false) as a documented exception, not a habit.