[Feature]: Automatic waiting to resolve strict mode violations

[ErikBrendel]

🚀 Feature Request

When there is a strict mode violation, instead of immediately raising an exception, wait the usual time for the strict mode violation to resolve

Example

In a test scenario, where an open dialog should be closed by clicking the close button:

await page.getByLabel('close').click();

If there are still some auto-disappearing toast messages visible on the page, and they have a dismiss-button with the same label, the test will immediately crash.

Current workaround:

await expect(page.getByLabel('close')).toHaveCount(1);
await page.getByLabel('close').click();

Suggested change:

Instead, each action that would raise a strict-mode-violation should first perform an expect wait like from the workaround, and only actually fail when the violation is still present after the timeout.

Motivation

It would make workarounds like above unnecessary, and also align the code generated from the recording feature more aligned with the actual working test code.

[dacloutier-logmein]

I like the idea, also had to cope with similar problems.

[toduyemi]

Please this really should be a high priority. Playwright touts its auto-waiting and retry-ability especially when it comes to Locators. This behaviour has been documented (#30363) to be throwing false negatives for a while now.

Currently I have multiple flakey test scenarios where I navigate to a new page, then click on a button. Playwright throws a strict mode violation while the new page has barely started loading, due to the previous page having elements that match the button Locator. I've currently worked around around with load state waits, but even that's still inconsistent, i might have to turn to hard waits.

This behaviour of throwing an error and failing the test before the browser has even registered the previous action violates the philosophy of Locators and their in-built auto-wait and auto-retry mechanism. This is the exact sort of flakey behaviour that playwright locators are designed to avoid. Why are strict-mode errors a fail-fast exception to this?

[MiladSadinam]

I would also highly appreciate this, as we regularly have flaky strict mode violations because there is no auto-waiting on that check.

It is just practically not feasible to add everywhere .toHaveCount(1) when the framework could take over this job.