Two matches need a product decision.

A settings page has two buttons called Apply. One belongs to weekly updates, the other to security notices. A generated test asks Playwright to click Apply and receives a strictness error. Adding first() makes the click run, but now document order decides which preference changes. The test needs the intended record, not a convenient position.

Playwright's locator guide documents strictness for operations targeting one element. Multiple matches make a click ambiguous. Operations intended for several elements, such as count(), can use a locator with several matches. A count of two and a failed click are therefore compatible observations.

Inspect both matches

Read the controls with their surrounding headings, labels and records. Check whether duplication is expected. A repeated label in separate cards can be a reasonable interface, while an accidental duplicate in one card can be a defect. Do not turn either possibility into a selector fix before looking at the product requirement.

Our invented page has two named regions. Each region contains an Apply button and a local status message. There is no server, real account or saved preference. The demonstration checks which visible region a scoped action changes and that its neighbor stays unchanged.

const weekly = page.getByRole('region', { name: 'Weekly updates' });
const apply = weekly.getByRole('button', { name: 'Apply', exact: true });
await expect(apply).toHaveCount(1);
await apply.click();
await expect(weekly.getByRole('status')).toHaveText('Applied');

The snippet requires the Playwright test runner and imported expect. The local fixture supplies the region name and button handler. Its status assertion proves a controlled interface effect; it does not prove persistence or delivery of a notice.

Give the scope a reason

Choose the parent from the record or component the user intended. An accessible region name works in this specimen. Other interfaces may need a row filtered by a stable record name or an explicit test identifier agreed with the product team. Verify that the scope still identifies the right record after sorting or insertion.

Exact button text narrows text matching. It does not distinguish two buttons with identical text in the same scope. The count assertion exposes a broken uniqueness assumption before the action. Keep a separate count for the whole page when the expected repeated structure is part of the requirement.

A locator is resolved when it is used. The page can change between observations, so a count is not a lock on a DOM node. Playwright's click still applies its own checks. Avoid explaining a preceding count as a guarantee against all later page updates.

Use positional choices only with an ordering contract

The guide warns that first(), last() and nth() can select an unintended element after a page changes. A position can be valid when the requirement is explicitly about ordering, such as the first ranked item. In that case, assert the ordering and identity that justify the position. An error disappearing is not that justification.

Our local test first confirms two global matches and catches the strict click error without changing either status. It then scopes the action to Weekly updates and checks the unchanged security region. This is a repeatable boundary test, not a diagnosis of every strictness error.

During review, record the intended component, why its identity is stable and what the action should change. AnyTest describes agents exploring apps and producing end-to-end tests for human review. Review repeated controls in that output against the intended record. No particular locator-selection behavior of AnyTest is claimed.