[Feature]: Choose which actionability checks to ignore

[SUSAltd]

🚀 Feature Request

Actions like locator.click() automatically perform a series of actionability checks to ensure that the target locator can be acted upon. Users can choose to ignore all actionability checks using the option force: true, but there's no way to specifically ignore just one actionability check. I think it would be useful to have a way to specify which actionability check to ignore.

Example

Imagine we want to click a button that is constantly animated (e.g. a small "breathing" animation). Since button.click() checks for stability before clicking, the only way to click this button is with force: true. But that forces us to skip all other actionability checks, even though we just want to ignore the stability check.

We could use something like await button.waitFor() to verify visibility, but then we still can't check that the button is enabled without resorting to an expect. And then there doesn't seem to be another way to check that the button can receive events.

Motivation

Including the option to ignore specific actionability checks would allow users to take advantage of Playwright's excellent auto-waiting capabilities to write more stable tests in cases where they would otherwise be forced to use force: true.

[pavelfeldman]

I'd say 3 line workaround (expect.toBeVisible, expect.toBeEnabled and locator.click(force)) is a fine workaround for a rare case of breathing button!

[SUSAltd]

Thanks for the reply @pavelfeldman 🙂

I'd say 3 line workaround (expect.toBeVisible, expect.toBeEnabled and locator.click(force)) is a fine workaround for a rare case of breathing button!

That is what I'm currently doing, but in my case the breathing button is sometimes blocked by an overlay element which intercepts pointer events. Key word is "sometimes"; I use a locator handler to dismiss that overlay, but using .click(force) causes the click to happen before the locator handler gets a chance to finish running, so then the button never gets clicked.

As an aside, I personally avoid using expects in our page object fixtures (to keep "test logic" contained in test specs), so it could alternatively be nice to have waitFor(enabled) and waitFor(receivesEvents), which would allow for a four-line workaround 🙂

[pavelfeldman]

We won't be able to do waitFor(receivesEvents) as it is only checked during the click itself. The other conditions we can check w/o problem. It'll be racy though, so sounds like you do need to remove exactly the 'stable' check from the click. Let me discuss it with the team.