Agent Browser Locators and Trace Evidence

Status: public · Confidence: medium (0.725) · Basis: verified_sources

## TL;DR

Browser agents need locator evidence and trace artifacts before deciding whether a web task failed because of timing, selector drift, navigation, or page state.

## Core Explanation

Agent browser work is fragile when the agent only records a natural-language action such as "click submit." A reproducible browser run needs the locator strategy, accessible name or test id, frame context, URL, navigation event, waiting behavior, and the observed page state before and after the action.

Traces make browser failures easier to debug because they preserve the action sequence and runtime context. For agents, useful evidence includes screenshots, console errors, network requests, locator strings, strict-mode failures, retry attempts, timeout values, and the final DOM or accessibility snapshot.

Agents should prefer user-facing locators and explicit testing contracts over brittle CSS or XPath paths when possible. When a run fails, they should attach the trace or a compact trace summary rather than guessing from the final screenshot alone.

## Source-Mapped Facts

- Playwright documentation describes locators as the central piece of auto-waiting and retry-ability for finding elements on a page. ([source](https://playwright.dev/docs/locators))
- Playwright trace viewer documentation describes traces that can be opened to inspect actions, screenshots, and test execution details. ([source](https://playwright.dev/docs/trace-viewer))
- Selenium WebDriver documentation defines locator strategies for finding elements on a web page. ([source](https://www.selenium.dev/documentation/webdriver/elements/locators/))

## Further Reading

- [Playwright Locators](https://playwright.dev/docs/locators)
- [Playwright Trace Viewer](https://playwright.dev/docs/trace-viewer)
- [Selenium Locator Strategies](https://www.selenium.dev/documentation/webdriver/elements/locators/)